I have a maven project that uses the maven-shade plugin to bundle a common-code-library jar into several distributed software plugins I make.
These plugins are all for the same main application - so when someone uses more than one plugin, it becomes a problem because each plugin has a copy of the shaded lib and they're not always using the same version.
I'm not sure how to resolve this. Is there a way I can configure maven to make two builds - one with the library shaded in, and one without? For the one without, we'll provide only one copy of the library needed as a separate resource.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<configuration>
<artifactSet>
<includes>
// our common lib
</includes>
</artifactSet>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Just change the finalName configuration property of shade plugin. See here. It's just overwriting your original package. If you change the output name both packages will be left.
You can use something like
<configuration>
...
<finalName>${build.finalName}-nodep.jar</finalName>
</configuration>
You can alternatively change outputFile or outputDirectory
Also if you want to preserve original artifact name but use classifier set shadedArtifactAttached to true.
The solution to my issue is to relocate the classes I'm shading, so they won't load copies found in other jars:
http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
Related
In my maven project I have plenty of dependencies which source code I need to get.
I know there is maven-dependency plugin with unpack-dependencies goal in it
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>resolve-dependecies</id>
<phase>process-sources</phase>
<goals>
<goal>sources</goal>
</goals>
<configuration>
<classifier>sources</classifier>
<includeParents>true</includeParents>
<type>java-source</type>
</configuration>
</execution>
<execution>
<id>src-dependencies</id>
<phase>process-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<classifier>sources</classifier>
<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<outputDirectory>${project.basedir}/Utils/src</outputDirectory>
<type>java-source</type>
</configuration>
</execution>
</executions>
</plugin>
But when I use it a lot files "have NOT been resolved".
e.g.
...
org.jboss:jboss-parent:java-source:sources:5
org.apache.cxf:cxf-parent:java-source:sources:3.0.3
org.apache:apache:java-source:sources:13
org.apache:apache:java-source:sources:9
org.liquibase:liquibase-parent:java-source:sources:3.5.0
org.apache.commons:commons-parent:java-source:sources:5
org.eclipse.jetty.orbit:jetty-orbit:java-source:sources:1
...
In pom.xml I didn't specify any repository for dependencies, so by default maven central repository is using.
I also tried to decompile (Fernflower, Procyon, JAD projects) my project jar file which contains all dependencies. But after decompiling hundreds of errors appeared in result java files.
I still hope to solve this issue using maven tools.
Thanks in advance for any help.
EDIT
Unresolved artifacts directly not specified in pom.xml
I see a couple of dependencies with *-parent. Given the name I guess these are merely parent poms which probably don't contain any java sources. For the remaining ones, are you sure that there are artifacts with the java sources?
UPDATE: I checked the list you shown within your question whether there are sources and there weren't. What I noted is that all of them have packaging POM. You might skip these by including <includeClassifiers>sources</includeClassifier> within your configuration
There is this maven module, say prj-package-module, to package the project artifacts into a tar file using maven-assembly-plugin. There are also jars added as dependencies in the prj-package-module/pom.xml and packaged into the tar file.
Now the requirement is to add a file, prj-pakacge-module/src/main/resources/file.xml to one of these dependency jars before packaging into the tar file. How can I achieve this?
Edit: The file is a JNLP with list of dependency jars dynamically added to it. For security reasons, Javaws also requires the JNLP file to be added a jar and the jar to be signed. This is where I hit the problem.
Here is a maven solution to dynamically unpack an existing dependency, add (copy) a resource to the unpacked folder, repack (jar) the hole and as such get a modified copy of the initial jar.
A sample pom file doing exactly that for the junit dependency:
<build>
<plugins>
<!-- unpack step -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>unpack</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<type>jar</type>
<outputDirectory>${project.build.directory}/unpack-tmp</outputDirectory>
<includes>**/*.class,**/*.xml</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<!-- add the additional resource step -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/unpack-tmp</outputDirectory>
<resources>
<resource>
<directory>src/main/resources</directory>
<include>test.properties</include>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<!-- repack step -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>repack</id>
<phase>prepare-package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classesDirectory>${basedir}/target/unpack-tmp</classesDirectory>
<finalName>junit-modified</finalName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
What it is actually doing:
As part of the prepare-package phase we are adding three steps to create a modified jar from a dependency
First step: unpack the dependency via the Maven Dependency Plugin and its unpack goal: an unpacked folder will be created to the tmp folder unpack-tmp
Second step: copy the concerned resource via the Maven Resources Plugin and its copy-resources goal.
Third step: re-pack the whole via the Maven Jar Plugin and its classic jar goal
Running the sample above, the junit-modified.jar file will appear in the target folder of the maven project.
The order of the plugin configurations above is important to respect the steps flow as part of the same phase.
Then, you have one additional file to add to your fat-jar, which is indeed the modified jar you were probably looking for.
If you don't need a dynamic approach, a better approach would be to do it once and have a classified version of that dependency as explained in this other SO post.
Alternatively, move it to a Maven profile so that at least it is not part of the default build.
It seems that you're trying to modify a dependency of the maven project before packaging it into the final artifact of the project.
This is dodgy. If that jar/library (the dependency) is yours, then modify the pom of that jar, rebuild it, and then have the current project resolve the latest artifact.
If, otherwise, the dependency jar is not yours, then it should suffice to have the resource (prj-pakacge-module/src/main/resources/file.xml) in the current project (the one you're building now), as the end result will be the same (as long as the assembly plugin is set to flatten all artifact jars in the target uber/fat jar...
When I create a jar file I want to fit inside my dependencies. For that, I use maven-assembly-plugin such as follows:
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<finalName>${project.artifactId}-GUI</finalName>
<archive>
<manifest>
<mainClass>gui.MyMainClass</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<!-- <appendAssemblyId>false</appendAssemblyId>-->
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
This code works OK and it does what it's expected to do. However, this creates a new jar called myjar-GUI-jar-with-dependencies.jar. I would like to eliminate that "jar-with-dependencies" ending. Does anybody knows how to do that?
I have used that commented line you can see on my code, but that produces the following warning that I don't know how to solve it:
[WARNING] Configuration options: 'appendAssemblyId' is set to false, and 'classifier' is missing.
Instead of attaching the assembly file: [myJar-GUI].jar, it will become the file for main project artifact.
NOTE: If multiple descriptors or descriptor-formats are provided for this project, the value of this file will be non-deterministic!
[WARNING] Replacing pre-existing project main-artifact file: [myJar].jar with assembly file: [myJar-GUI].jar
EDITED
After the solution the user Tunaki suggested, I used a different pluggin and maven works as I want it to do it. The code is as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
<configuration>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>gui.SparkISGUI</mainClass>
</transformer>
</transformers>
</configuration>
</plugin>
First, you need to understand why you are getting this warning.
The Maven convention is that one project should create a single main artifact. For a project of packaging jar, the main artifact is the result of the maven-jar-plugin. This plugin will package as a JAR the classes contained in your project only.
One project can eventually generate additional artifacts that will be distinguished from the main one by their classifier:
Beside the main artifact there can be additional files which are attached to the Maven project. Such attached filed can be recognized and accessed by their classifier.
The classifier is an identifier than will be appended to the main artifact name.
So what happens when you want to create an uber-jar? Somehow, your project needs to generate two jars. The main one will be a JAR containing the classes of your project and the second one will be the uber-jar resulting of maven-assembly-plugin. To distinguish this secondary additional artifact from the main one, the classifier jar-with-dependencies is added.
So when you remove the classifier, you effectively replace the main artifact with the uber-jar. maven-assembly-plugin will emit a warning in this case, and that's the warning you are having. You can ignore it completely: it just reminds you that you are replacing the main artifact of the project by an additional artifact.
Besides the maven-assembly-plugin, do note that you can also generate an uber-jar with the maven-shade-plugin:
This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.
Is there a way to add an arbitrary classpath entry to a JAR file manifest using onejar-maven-plugin?
I found the way to configure maven-jar-plugin to do this, but it appears that there is no such option for onejar-maven-plugin.
This is not done to find additional classes (otherwise why use the onejar plugin, right?), but rather to locate a configuration file that must be external to the JAR.
Is there a direct solution or a workaround for this?
Is the usage of the one-jar plugin really required?
You can achieve the same goal (packaging in one single jar your application AND all the required dependencies, including transitive ones, AND add configuration for Class-Path AND using a more stable/standard plugin) applying the following approach:
Configure the Class-Path entry in your application Jar using the Maven Jar Plugin and the approach you mentioned in the question
Use the Maven Assembly Plugin to package one single JAR including dependencies, as explained here, in another stackoverflow question/answer.
An example of one-jar executable file (without using the one-jar plugin) could be as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<!-- your further configuration here -->
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>com.sample.MainApp</mainClass>
<!-- your further configuration here -->
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
If you need to further play with classpath and Maven, I would suggest to also check this question here on stackoverflow.
Adding arbitrary manifest entries is possible in 1.4.5:
<plugin>
<groupId>org.dstovall</groupId>
<artifactId>onejar-maven-plugin</artifactId>
<version>1.4.5</version>
<executions>
<execution>
<configuration>
<manifestEntries>
<Build-Status>Yes</Build-Status>
</manifestEntries>
</configuration>
<goals>
<goal>one-jar</goal>
</goals>
</execution>
</executions>
</plugin>
The onejar-maven-plugin project doesn't seem to be in active development anymore, so you might want to switch to other solutions (e.g. maven-assembly-plugin) eventually.
The plugin is not available on Maven Central. Someone else put up a version of it to Maven Central with a different group ID.
Additional libraries can be added to the classpath at the time of launch.
The property one-jar.class.path can be used
one-jar.class.path
Extra classpaths to be added to the execution environment. Use platform independent path separator '|'
Example: --one-jar.class.path="./lib/two.jar|/opt/lib/three.jar"
Source: http://one-jar.sourceforge.net/index.php?page=details
I already have a working solution where I can specify with maven which classes to not compile when using a particular maven profile.
But I would like to use a general solution and use an annotation instead
The current solution that I have is like
<plugin>
<!-- Exclude some web services used only for internal testing -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<optimize>true</optimize>
<excludes>
<exclude>**/something/*ClassPattern.java</exclude>
</excludes>
<testExcludes>
<exclude>**/something/*ClassPatternTest.java</exclude>
</testExcludes>
</configuration>
</plugin>
But Some thing like
#NotCompiledForProduction
would be rather nice on top of a class.
It seems to me that this might be hard (or impossible to do) without changing maven's behaviour. That is not the scope here. And this kind of annotation
You cannot (I assume) use an annotation to determine what source code gets presented to the java compiler, because you need to compile the source code in the first place to process the annotation.
It seems like you need to create different modules in your maven project: one that generates a jar file with the production code, and one module that generates a jar file with testing implementation with a dependency on the production artifact.
If the code really does need to be in the same maven module, then the code should always be compiled. You can however use maven-jar-plugin to create multiple artifacts at the package phase: the default artifactId.jar, and an artifactId-test-lib.jar artifact. You can do this by specifying multiple executions for the plugin, and using <includes> and <excludes> to split the jar files as required.
you can try this...
<build> <plugins>
<!-- Run annotation processors on src/main/java sources -->
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
</plugin>
<!-- Disable annotation processors during normal compilation -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
</plugins> </build>