I have a project where I am packaging a WAR using simple maven-war-plugin. Along with all other dependencies one of the dependency say 'abc.jar' which is getting packaged in war contains a default spring configurations which I would like to update with the custom one before packaging. I have maven profile configured to be activated if following build command applied;
mvn clean install -DframeworkPacakging=XYZ
I am trying to use 'truezip-maven-plugin' to overwrite my custom spring configurations inside in 'abc.jar' present in 'target/aretfacts-id/WEB-INF/lib' but when maven-war-plugin finishes I loose my changes because war plugin takes the file from dependency definition. How can I solve this issue and what are my options?
P.S. Distributing configuration is not desirable as this setup would be used for Embedded Jetty Server running within Eclipse
to prevent inclusion of the original jar file, I would use go for approach suggested on: https://www.mail-archive.com/users#maven.apache.org/msg38537.html
Use <scope>provided</scope> for this dependency to keep it out of the
lib directory.
to include the repackaged one, I'd follow suggestion from: How to make Maven copy resource file into WEB-INF/lib directory?
Try changing the configuration of the maven war plugin to include a webResource:
<configuration>
<webResources>
<resource>
<directory>pathtorepackagedjar</directory>
<includes>
<include>**/abc.jar</include>
<includes>
<targetPath>WEB-INF/lib</targetPath>
</resource>
</webResources>
</configuration>
Related
The problem
I am faced with the following scenario:
The sources of an Eclipse test plugin (tycho packaging type eclipse-test-plugin) depend on a "plain" jar (read: non-OSGi jar). I managed to get the tests to compile and run in Eclipse, however when running Maven/Tycho from the command line, tycho-surefire-plugin fails to execute the tests because the jar is not visible at test time. This results in a java.lang.NoClassDefFoundError while attempting to load a class from the jar.
Looking at mvn -e -X output does not reveal anything significant.
My question is, how can I include the jar in the classpath of tycho-surefire-plugin when running Maven/Tycho from the command line?
Attempts
Here is everything I have tried so far:
Use <extraRequirements> as per the tycho-surefire-plugin documentation. This however fails because the jar's packaging type is jar, while <extraRequirements> expects one of the eclipse-xxx packaging types.
For a good measure I also tried
<configuration>
<dependencies>
<dependency>
<groupId>. . .</groupId>
<artifactId>. . .</artifactId>
<version>. . .</version>
<scope>system</scope>
<systemPath>path-to-the-jar</systemPath>
</dependency>
</dependencies>
</configuration>
but the packaging type is still considered to be jar.
Use <argLine> as per tycho-surefire-plugin documentation:
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<configuration>
<argLine>-cp path-to-the-jar</argLine>
</configuration>
however this appears to have no effect as the java.lang.NoClassDefFoundError persists.
Include the jar in the Eclipse test plugin. The jar is present in the MANIFEST.MF
Bundle-ClassPath: the.jar
in the build.properties
bin.includes = META-INF/,\
the.jar
and in the .classpath (although this doesn't matter for tycho-surefire-plugin).
<classpathentry exported="true" kind="lib" path="the.jar"/>
tycho-surefire-plugin once again reports java.lang.NoClassDefFoundError.
Create a dedicated Eclipse plugin to house the jar. This is for the most part equivalent to 3, where the Eclipse test plugin simply depends on this new dedicated Eclipse plugin. The java.lang.NoClassDefFoundError still rears its head.
Transition to Tycho 2.x.x since it supports the Directory location type. Unfortunately it is not possible to include the jar in the target definition because its packaging type is jar.
I have a maven project with log4j2 (2.9.0) and a configuration file in /src/main/java/resources/log4j2.xml. As long as I stay in IntelliJ this works fine and it logs just like I configured it.
If I now make a mvn clean install in the terminal (Ubuntu 14) and then start the main method of my program in IntelliJ, I will get an error that it won't find the log4j2 configuration file:
ERROR StatusLogger No log4j2 configuration file found. Using default
configuration: logging only errors to the console. Set system property
'log4j2.debug' to show Log4j2 internal initialization logging.
As soon as I make Build -> Rebuild Project in IntelliJ IDEA it will work again.
I don't really understand how an external maven build could confuse IntelliJ IDEA to not take the .xml in the local source code.
Any idea?
I found the solution.
IntelliJ copies the resources per default to /target/classes and that's the place where IntelliJ actually takes the log4j2.xml from. My maven build didn't do that and IntelliJ didn't rebuild the project, so it couldn't find the log4j2.xml
My solution was to put the log4j2.xml in a resource section of the pom:
<resources>
<resource>
<directory>src/main/resources</directory>
<targetPath>${project.build.directory}/classes</targetPath>
<includes>
<include>**/log4j2.xml</include>
</includes>
</resource>
</resources>
I have a regular maven jar project, which has dependencies such as the reflection library and I want to
convert it to osgi, what Ive already done.
created a common interface layer in a different (maven) jar
project and added it to the bundle as a dependencies.
changed the type of the osgi-module-to-be to 'bundle'.
created an implementation of BundleActivator
added this plugin the pom:
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>my.package.MyServiceActivator</Bundle-Activator>
<Export-Package>
my.package.exp.*
</Export-Package>
<Import-Package>
!org.reflections,???
</Import-Package>
<Embed-Dependency>
slf4j-api;scope=compile,???
</Embed-Dependency>
</instructions>
</configuration>
here is where it gets lost, I need to figure out the "Import-Package" and "Embed-Dependency"
and, even more important figure how to deploy it on glassfish as a zip or,
maybe, ORB (or Gogo) so that it will deploy with all it's dependencies jars.
any ideas?
G.
BTW: the org.reflections package is not OSGi ready
It seems you're confused about how OSGi and the Maven Bundle plugin work.
Maybe reading the Felix guide will help you:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
Basically, you should have something like this:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>my.package.MyServiceActivator</Bundle-Activator>
<Export-Package>
my.package.exp.*
</Export-Package>
<Import-Package>
!org.reflections*,*
</Import-Package>
<Embed-Dependency>
org.reflections
</Embed-Dependency>
</instructions>
</configuration>
</plugin>
By default (ie. if you just omit it, which is usually the case), your Import-Package instructions would be *, which means anything you refer to in the code which is not in java.* or in your own bundle should be imported. But as you have a dependency on a non-bundle jar you want to embed, you need to tell the plugin that by using the expression !org.reflections*,*, which means you don't want to import the org.reflections package but everything else is fine. You also need to declare that any artifactId called org.reflections should be embedded in the jar by using the Embed-Dependency instruction.
BTW, You most likely don't want to embed your logging framework SLF4J implementation, let alone the API, as just about any OSGi environment should provide a logging implementation for you.
After you package your bundle (mvn package or just mvn install) make sure to check the generated MANIFEST to ensure that it looks like everything is correct (importantly, check the Import-Package packages and see if your environment will have all bundles which provide such packages).
Once you get your bundle set up correctly, deploying it is trivial. Just drop it into your framework's bundle directory, ensure all other bundles you need are also there, and everything should work fine.
As a side note, you might want to consider wrapping the non-bundle JAR you need as a bundle by using PAX-WRAP or just Karaf (just throw a JAR in the deploy folder and you will get it wrapped as an OSGi bundle immediately), for example.
I want to make the build process for my Eclipse RCP plugin fully automatic. It has some third-party jar dependencies (available from Maven repositories) which are not distributed as OSGi bundles, and currently I use the "Eclipse plugin from existing JAR archives" wizard to convert them manually. Can PDEBuild or Maven/Tycho (or perhaps some other build system) do it as a step of the build?
Peter Tillemans mentioned the PAX wrap jar command in this post
The Maven bundle plugin from Apache Felix may be worth a look, too.
Maybe the Bundlor tool from SpringSource can handle the creation of osgi bundles from jar, too.
Checkout the p2-maven-plugin developed by me. It's an open-source, community-friendly plugin that handles:
the wrap of the jars that are not OSGi bundles (that's fully customizable)
the generation a fully functional p2-update site that may be consumed in the Eclipse PDE
the generation of the corresponding source bundles (it generates source bundles for all the bundles)
Details and the documentation could be find here: http://projects.reficio.org/p2-maven-plugin/manual.html
Sample usage:
<plugin>
<groupId>org.reficio</groupId>
<artifactId>p2-maven-plugin</artifactId>
<version>1.0.0-SNAPSHOT</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<artifacts>
<!-- specify your depencies here -->
<!-- groupId:artifactId:version -->
<artifact><id>commons-io:commons-io:2.1</id></artifact>
<artifact><id>commons-lang:commons-lang:2.4</id></artifact>
<artifact><id>commons-lang:commons-lang:2.5</id></artifact>
<artifact><id>commons-lang:commons-lang:2.6</id></artifact>
<artifact><id>org.apache.commons:commons-lang3:3.1</id></artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
Take a look on the differences between the thirdparty jar and its bundled equivalence. It's just an additional plugin.xml and a few extra lines in the manifest.
Write your own code for bundling jars.
If I was to use a 3rd party library that was not in the maven public repository, what is the best way to include it as dependency for my project so that when someone else checks out my code it will still be able to build?
i.e.
My Application "A" depends on jar "B" which does not exist in the public repository. I, however, wish to add "B" as a dependency to "A" such that when a person on the other side of the world could check out the code and still be able to build "A"
You can install the project yourself.
Or you can use the system scope like the following:
<dependency>
<groupId>org.group.project</groupId>
<artifactId>Project</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/project-1.0.0.jar</systemPath>
</dependency>
systemPath requires the absolute path of the project. To make it easier, if the jar file is within the repository/project, you can use ${basedir} property, which is bound to the root of the project.
If you have a parent project with a module that is in this situation (requires a dependency not in a repository) you can setup your parent project to use the exec-maven-plugin plugin to auto-install your dependent file. For example, I had to do this with the authorize.net jar file since it is not publicly available.
Parent POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<inherited>false</inherited>
<executions>
<execution>
<id>install-anet</id>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>mvn</executable>
<arguments>
<argument>install:install-file</argument>
<argument>-Dfile=service/lib/anet-java-sdk-1.4.6.jar</argument>
<argument>-DgroupId=net.authorize</argument>
<argument>-DartifactId=anet-java-sdk</argument>
<argument>-Dversion=1.4.6</argument>
<argument>-Dpackaging=jar</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
In the above example, the location of the jar is in the lib folder of the "service" module.
By the time the service module enters the validate phase, the jar will be available in the local repository. Simply reference it in the way you set up the groupid, artifact, etc in the parent pom. For example:
<dependency>
<groupId>net.authorize</groupId>
<artifactId>anet-java-sdk</artifactId>
<version>1.4.6</version>
</dependency>
Using system scope may work but it is not recommended even in the Maven specification.
it is not portable.
from Maven book:
system- The system scope is similar to provided except that you
have to provide an
explicit path to the JAR on the local file system. This is intended to allow compilation
against native objects that may be part of the system libraries. The artifact is assumed
to always be available and is not looked up in a repository. If you declare the scope to
be system, you must also provide the systemPath element. Note that this scope is not
recommended (you should always try to reference dependencies in a public or custom Maven
repository).
The best approach is to install to your local repository or to your enterprise repository to be accessible to all your peers.
this is very easy if you are using a repository manager such as Nexus.
This solution worked for me;
1. Created a local-maven-repo in my project's root directory and copied all my jars in the
2. Executed the following command to generate the necessary pom files and metadata etc for each and every jar that I needed to use;
mvn deploy:deploy-file -DgroupId=<somegroupid> -DartifactId=<someartifact> -Dversion=1.0.0 -Durl=file:./local-maven-repo/ -DrepositoryId=local-maven-repo -DupdateReleaseInfo=true -Dfile=<path to jar file>
This generated a new jar file with a pom file inside the local-maven-repo and I was able to include into my project as a dependency like this;
<dependency>
<groupId>somegroupid</groupId>
<artifactId>someartifact</artifactId>
<version>1.0.0</version>
</dependency>
Then mvn package ensured that my project dependencies are resolved and packaged with my war file.
If you are using groovy/grail tool suite (GGTS) then you can directly import that third party dependency (but be sure you have that third party dependency in your local repository) using below steps :
Go to the Project Explorer and right click on project.
Click on import option.
Expend the maven option and select Install or deploy an
artifact to a maven repository and click next.
Brows and select that third party dependency using Artifact File
option and enter the detail of Group Id, Artifact Id and Version
using POM.xml file and click on finish
Wait some moment and possibly error would have gone for that problem.
Generally speaking, you should first put the 3rd party jar into your local repository. After that you can use it by adding the dependency into pom.xml.
For example.
1.put the jar into your local repository first:
mvn install:install-file -Dfile=<path-to-file>
Note: this command requires maven-install-plugin version 2.5 or later. If not, You can refer to Here
2.use the jar by adding the dependency into you project's pom.xml.
just add this into the pom.xml of your project:
<dependency>
<groupId>${the groupId in the jar's pom.xml}</groupId>
<artifactId>${the artifactId in the jar's pom.xml}</artifactId>
<version>${the version in the jar's pom.xml}</version>
</dependency>
3.you can then package or deploy your project by running mvn package or mvn deploy
The 3rd party jar will also be included in the package.