I currently have a Java testing library which is built with Maven, and distributed as a jar. My project depends on a very common library (Objectweb ASM), and I've experienced problems where an earlier and incompatible version of ASM is already on the classpath. Thus, I've started usings the jarjar-maven-plugin to create jar, repackaging ASM internally where it cannot conflict with another version of ASM.
This executes fine, and my library can be pulled in as a dependency with no problem.
However, because my project has compile-scope dependencies on ASM, whenever a client project adds my library, the transitive dependencies are all pulled in as well. So, hypothetically, if they use a particular version of ASM, and they also add the version I depend on to the classpath, they have undefined behaviour. I'd like to avoid this situation, and allow clients to depend on the JarJar'd artifact without having Maven pulling down the transitive dependencies both unnecessarily and potentially dangerously.
How do I create a JarJar'd artifact which users can depend on without pulling transitive dependencies?
I found a solution to this problem by ditching the jarjar-maven-plugin, and reverting to the maven-shade-plugin. This allows repackaging classes within your own namespace, setting the main class of the jar, and crucially, rewriting the generated pom to not include the compile time dependencies which are now bundled.
The part of my pom.xml which acheived this is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<shadedArtifactAttached>false</shadedArtifactAttached>
<createDependencyReducedPom>true</createDependencyReducedPom>
<relocations>
<relocation>
<pattern>org.objectweb.asm</pattern>
<shadedPattern>${repackage.base}.org.objectweb.asm</shadedPattern>
</relocation>
</relocations>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>${package.base}.my.MainClass</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
The important parts of this configuration are:
shadedArtifactAttached which when set to false, means the shaded jar will replace the main artifact that would normally be produced. This defaults to false but it's worth pointing out.
createDependencyReducedPom which when set to true means that when the shaded jar is deployed or installed, the pom.xml which is deployed will not include the compile-scope dependencies which have been repackaged into the jar.
relocation these elements configure how files within the dependencies are repackaged into the shaded jar. In the above example any class whose canonical name begins with org.objectweb.asm will be moved to ${package.base}.org.objectweb.asm, and thus when packaged in the jar will have the equivalent file path within the jar.
With this configuration, when my project is deployed, when clients declare a compile-scope dependency on my project, it only pulls in the shaded jar, and no transitive dependencies.
Consider trying the maven-shade-plugin instead, which allows all sorts of fine control.
Perhaps setting the <optional> attribute will work in your case. Specifying something like the following in your java testing library pom.
<dependencies>
<dependency>
<groupId>asm.group</groupId>
<artifactId>asm</artifactId>
<version>x.y</version>
<optional>true</optional>
</dependency>
...
</dependencies>
Related
The project has the following structure:
FatJarRootPom has dependencies for X and Y.
FatJarA and FatJarB all declare FatJarRootPom as their parent so they get its dependencies X and Y shaded into their JAR along with their own dependencies.
The issue is that, Shade Plugin will leave reference to parent in the dependency-reduced-pom.xml so FatJarA's pom will still explicitly depend on X and Y despite having them inside JAR already.
Flatten Plugin can get rid of parent so it would be optimal to run Shade Plugin on flattened pom. It will process all dependencies and then remove them from dependency-reduced-pom.xml. However, when I configure Flatten Plugin, Shade Plugin will not pick up its output and will still produce incorrect pom.
I have found this answer which suggests changing the invocation order of shade and flatten so that shade comes first, but it won't work since dependencies from FatJarRootPom will still be in the pom, which I am trying to avoid.
Maybe there is some other way of just removing parent section from dependency-reduced-pom.xml without flatten plugin?
Update: I have tried changing my FatJarRootPom to a POM dependency FatJarPom with transitive dependencies listed in it, and amusingly, Maven Shade Plugin will specifically skip POM dependency and will not remove it from dependency reduced POM, even as it would mean that all shaded dependencies will absolutely appear as dependencies of fat-jar artifact.
I have overlooked that Flatten Plugin has "fatjar" mode which will strip all dependencies. It is a very coarse grained approach, but it should do in my use case.
So the solution is placing
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.2.7</version>
<executions>
<execution>
<id>flatten</id>
<phase>package</phase>
<goals>
<goal>flatten</goal>
</goals>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>fatjar</flattenMode>
</configuration>
</execution>
...
after the corresponding Shade Plugin section.
What I am trying to do, is to obfuscate a certain packages in a multi module application, before it gets installed to my local repository, so that the final package will be an EAR file which contains obfuscated jars.
I tried to obfuscate the jars during EAR building process without success. Now i want to build the EAR with obfuscated jars instead ob obfuscating then during the build.
So I've got the following plugin configuration:
<plugin>
<groupId>com.github.wvengen</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.11</version>
<dependencies>
<dependency>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard-base</artifactId>
<version>${version.proguard}</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
...
</configuration>
</plugin>
So there are two problems for me:
Progruard always runs after the install phase, so that the EAR build always gets the not obfuscated jars
I always have to add proguard:proguard to the maven command, which of course fails in a multi module project where some modules don't have to be obfuscated
So my questions:
How can I obfuscate the package before it gets installed?
How can I make plugins like this one run on default without adding <phase>:<goal> to the maven call?
Thnx.
It seems that for the proguard plugin to work, JAR files are needed. Perhaps you can achieve this by attaching the proguard plugin's proguard goal to the package phase (and not process-classes phase) of the default Maven build life cycle as proposed here by Alexey Shmalko. It's not clear to me if you are using the maven-shade-plugin, but if you are, then place the proguard plugin configuration your in pom.xml after that of maven-shade-plugin (this is because both these plugin attach to the same phase: package).
My expectation is that since package phase is achieved before install phase, it should give you the effect you are looking for.
It seems that including direct dependencies with provided scope is well understood. It also appears that including transitive dependencies with runtime scope is also easily accomplished.
But how can I include a dependency two levels of indirection away?
Example:
A --> B --> C
Where A depends on B (compile scope) and B depends on C (provided scope).
I want A to retrieve C (eg: download the jar locally), be it via assembly descriptor or maven-dependency-plugin:copy-dependencies or some other mechanism.
I've tried seemingly every combination of options for both of the aforementioned plugins. Neither approach covers this scenario. They both get B (even if B is changed to a provided dependency), and any compile scope dependencies of B, but not provided dependencies of B.
I suppose that I'm trying to do something similar to a shaded representation of my project but without unpacking dependencies.
Naturally I don't want to have to enumerate all of B's dependencies in A's pom - I'd like to retrieve (and then package) all dependencies implicitly and recursively.
You won't be able to do that. It is not a limitation of the maven-assembly-plugin, but the way Maven considers transitive dependencies. A transitive dependency that is of scope provided will be omitted, always (refer to this table in the documentation).
There is an open bug about this (MNG-2205) but I don't think it will be fixed anytime soon. This really is intended behaviour because provided dependencies, as per the name, as supposed to be provided at runtime.
Although Tunaki is quite right, I found a workable solution that's better than nothing, using a less well-known plugin (NOTE: only works with Maven <= 3.0.X)
This specifies two dependency blocks. The first pulls in normal compile deps including transitive, it's the same as using copy-dependencies. The second block specifically mentions B in addition to the normal pom dependency declaration (unfortunately, but at least both dependency mentions are in the same pom) and requests its provided deps:
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>get-provided-dependencies</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<resources>
<resource>
<targetPath>${project.build.directory}/lib</targetPath>
<dependencies>
<dependency>
<includeScope>compile</includeScope>
</dependency>
<dependency>
<groupId>some.group</groupId>
<artifactId>artifact_i_call_B</artifactId>
<version>1.0</version>
<includeScope>provided</includeScope>
</dependency>
</dependencies>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
Docs for this plugin may only exist in the archive at this point, not sure what happened to it:
http://web.archive.org/web/20130826193436/http://evgeny-goldin.com/wiki/Copy-maven-plugin
I'm working with a situation where we are using the LATEST and RELEASE keywords in our POM for a certain dependency (both the dependency and the project are owned by us, so we control what is LATEST and RELEASE...and we only support one version at a time). Using these keywords allows us to minimize maintenance needed after a release.
There is a step in the build process that must copy DLLs from the unpacked dependency, but since we don't specify a specific version we have the version number of the unpacked dependency hard-coded and have to update it after every release. Is there a way get the version of this dependency at run-time from a Maven property?
The properties goal of the maven-dependency-plugin (http://maven.apache.org/plugins/maven-dependency-plugin/index.html) gets the location of the artifact in the local repository (which is not what I'm looking for). The depends-maven-plugin (shown here: http://team.ops4j.org/wiki/display/paxexam/Pax+Exam+-+Tutorial+1) can generate a file that contains the various dependencies and their versions, but using that would require having a process read the file and utilize that information. I'm wondering if there is a more "Maven way", such as accessing a property for the dependency version.
EDIT: For clarification, we need the version number so we can get to the directory of the unpacked dependency to copy files.
I'm not sure what you mean with 'maven way' but I did something like this after looking at the same plugins you already mention:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.properties.put('firstdependencyinthepom', project.dependencies[0]['version'])
project.properties.put('seconddependencyinthepom', project.dependencies[1]['version'])
</source>
</configuration>
</execution>
</executions>
</plugin>
and then I was able to refer to versions of these dependencies with ${firstdependencyinthepom} and ${seconddependencyinthepom} respectively.
I feel a bit stupid about this question but i can't figure out how to add a SINGLE dependency (jdom.jar) into another jar.
Context: We developed a simple plug-in for our application, this plug-in have many dependency. We were using fatjar to include jdom.jar into it. I am trying to fix a bug in this plug-in, so i decided to "maven-ize" it at the same time. (We just switched to maven) This plug-in is loaded on the runtime so the only dependencies we want packaged with it is the jdom.jar.
Problem: I found that there is a maven fatjar plug-in! Unfortunately i could not find any documentation and this maven plug-in add EVERY dependency into the ouput jar. After many try i decided to give up on this fatjar plug-in and searched for another one. I found one-jar , shade but after a quick read on them they look like they add every dependency.
Question: what would be a simple way to add only jdom.jar into my plug-in jar like this:
-MyPlug-in.jar
|
|-src
|-main
|-java
|-*.java
|-jdom.jar
Also I don't want to alter the manifest or the output jar filename
Thank a lots for your time.
There was no answer here regarding how to use maven to include one single jar-file with the maven-shader-plugin. It took me some time to figure out how to actually do that. Here is a snippet to include just the classes from the dependency com.googlecode.json-simple:json-simple.
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>com.googlecode.json-simple:json-simple</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
...
</project>
For this kind of purpose i would suggest to use the maven-shade-plugin which will create a ueber-jar which can be controlled in many ways.
With the shade plugin you can exclude things you don't like. But this might be caused by not using a separate maven module where you can control the dependencies.
Using maven Shade would work fine, one-jar would have done the job too.
But we finally decided that packaging jdom in our extension would be a bad practice.
So instead we gonna do this:
|-Root application Folder
|-Extension Folder
|-MyExtension.jar
|-libs Folder
|-jdom.jar
The jar into the lib folder will be loaded dynamically and won't be loaded if the extension cannot find the appropriate libs into the libs folder.
For the people who look to solve my primary problem please check out #khmarbaise Answer.