My goal is to merge two XML files (both named info.xml) which are in src/main/resources of two Maven modules (packaging:jar) into a target WAR archive.
proj1: contains src/main/resources/info.xml
proj2: contains src/main/resources/info.xml
web: web project which should contain a merged info.xml from proj1 and proj2. I declared the plugin in the web project:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.XmlAppendingTransformer">
<resource>info.xml</resource>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
To build the web project and its modules I have a build project with:
<modules>
<module>proj1</module>
<module>proj2</module>
<module>web</module>
<modules>
I tried using a mvn clean package command in the build project and as result my web/target/web.war contains the unpacked libs (ueber.jar which I don't really want) and NO merged info.xml files.
What am I doing wrong?!
You have to configure Transformers to merge files, since it often requires extra logic, especially XML. See Resource Transformers for the details.
Related
I have read everything I can find on solving this and my attempts still fail. The best I can do is to get the Javadoc of exactly one module to show up--the last one built. (For now, I'm not trying to bundle Javadoc into any JARs. I'm also not trying to do anything "site".) I just want to put Javadoc for easy access into a subdirectory under the project root.
Here's what's in my parent pom.xml:
<build>
<plugins>
.
.
.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<noqualifier>all</noqualifier>
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
<destDir>javadoc</destDir>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
What I'm putting into subordinate pom.xml files is identical to the above except for
<goals>
<goal>javadoc</goal>
</goals>
I have played with replacing the <execution> in the parent and sometimes subordinate pom.xml files with:
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
but it makes no difference.
I think the following configuration is the reason your reports get overwritten:
<configuration>
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
</configuration>
All module builds will be written to the same directory, hence overwriting the previous build.
The solution is to use the default output directory and configure the output directory for the aggregated javadoc instead. This way the reactor build will create javadoc output files in each module's target directory. These can then be used by the aggregate goal to be combined.
This can be done by configuring your parent POM as follows:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<!-- Default configuration for all reports -->
<noqualifier>all</noqualifier>
<destDir>javadoc</destDir>
</configuration>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
<configuration>
<!-- Specific configuration for the aggregate report -->
<reportOutputDirectory>${user.dir}/documents</reportOutputDirectory>
<destDir>javadoc</destDir>
</configuration>
</execution>
...
</executions>
</plugin>
...
</plugins>
</build>
(there is no need for any additional configuration in the module POM files)
The aggregated javadoc can now be created by running
mvn compile javadoc:javadoc javadoc:aggregate
(note that the compile or package goal is required for reactor to resolve inter-module dependencies)
I've a drop wizard project which has the following directory structure:
basedir
pom.xml
config.yml
src
main
resources
myresource.xml
The build portion of
<build>
<finalName>project-${version}</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>project-package.App</mainClass>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer">
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
When I run my code from Eclipse, I use command as follows:
$mypackage.App server config.yml
It works fine and I can read the file under resources directory.
When I use mvn to build, in the snapshot jar created, it does not include config.yml and the path to "myresource.xml" is missing even though it is included in the snapshot.jar in the basedir. So, when I run it from my jar file, my code does not find it as resources.
How should I change the pom.xml to include config.yml and package the resource directory such a way that it is accessible as resource.
It is really strange that
this.getClass().getResource("myresource.xml")
does work in IDE but NOT when you run it from a jar.
this.getClass().getResourceAsStream("myresource.xml")
works both inside IDE and from jar.
That resolves the resources issue. However, I need an answer for how to package config.yml file. Should I supply separately in addition to the jar file?
Is there a well-known way to create an uber source jar? In other words, a jar of all the source code for a project and all its dependencies (or at least those that have a -sources.jar)?
I've looked into doing it with the maven-assembly-plugin, but using a dependencySet with includes of *.*.*.sources.* (or *.sources) doesn't work because those are not actually dependencies of the project, and I don't want to add them all.
You can use the maven-shade-plugin to create an uber jar. Just include the following within your <build> tag -
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>source-jar</id>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createSourcesJar>true</createSourcesJar>
<artifactSet>
<includes>
<include>...</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
To modify the configuration, you can use Resource Transformers within org.apache.maven.plugins.shade.resource package.
And to define the contents of the jar, you can further use includes and excludes within the filters.
I found some information on working with sources in the maven-dependency-plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>src-dependencies</id>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<phase>prepare-package</phase>
<configuration>
<classifier>sources</classifier>
<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<outputDirectory>${project.build.directory}/sources</outputDirectory>
<includeGroupIds>{your group prefix}</includeGroupIds>
<includes>**/*.java</includes>
<includeScope>runtime</includeScope>
</configuration>
</execution>
So if I do that, and then run a maven-assembly-plugin referencing the unpacked files, I can do it in two steps.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<execution>
<id>uber-source</id>
<goals>
<goal>single</goal>
</goals>
<phase>package</phase>
<configuration>
<descriptors>
<descriptor>ubersource.xml</descriptor>
</descriptors>
<outputDirectory>${deploy.internal.directory}</outputDirectory>
<finalName>${project.artifactId}</finalName>
</configuration>
</execution>
</executions>
</plugin>
with a file set in the assembly descriptor ubsersource.xml:
<fileSet>
<directory>${project.build.directory}/sources</directory>
<outputDirectory>.</outputDirectory>
</fileSet>
And then I get my uber source jar...
There is perhaps a subtle distinction in the way the maven-assembly-plugin and maven-dependency-plugin treats sources. If you reference classifier sources in a dependencySet of an assembly descriptor, it looks for sources that are actual dependencies in your pom -- not that useful. However, in maven-dependency-plugin, referencing sources classifier means that sources of your dependencies. Hence why this solution works.
I also wrapped this up in my own plugin using mojo-executor to make it single step, and single declaration in my pom, but that's optional
This is a lot more pom code, but I like it better than the maven-shade-plugin because it does just what I want, and nothing more.
When a project uses the Maven-jar-plugin, it's easy to include a custom manifest file in the jar, but I can't find a way to do the same thing with Maven shade. How can I use my own manifest file while using the "Maven-shade-plugin"?
Additional details:
My custom manifest file is located in "src/main/resources/META-INF/MANIFEST.MF".
Maven is not including my file, instead it is being replaced in the final jar with a default Maven manifest file.
The reason I need a custom manifest file is to specify some JavaBeans classes in my manifest, for a swing component library. Multiple JavaBeans classes should be specified in the manifest file in the following format, as described here. Note that the empty lines (and the line grouping) are important for marking JavaBeans classes in the manifest.
Name: SomeBean1.class
Java-Bean: True
Name: SomeBean2.class
Java-Bean: True
Name: SomeBean3.class
Java-Bean: True
A list of attempted solutions (these did not work):
This code only works when using the Maven jar plugin (not shade).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
This link says "As with all the examples here, this configuration can be used in all plugins that use Maven Archiver, not just Maven-jar-plugin as in this example." Based on that advice, I tried the following code, but this did not work either. (Maven still replaced my manifest file with the default manifest file.)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>core</shadedClassifierName>
<createDependencyReducedPom>false</createDependencyReducedPom>
<minimizeJar>true</minimizeJar>
</configuration>
</execution>
</executions>
</plugin>
I cannot use the shade "ManifestResourceTransformer" as described here to do the job, for the following reason. I need to add JavaBeans classes to my manifest file as described above under "additional details". However, if I add manifest entries using the shade ManifestResourceTransformer, those entries are inserted into the manifest file in an unpredictable (random-seeming) ordering. For specifying JavaBeans classes, the ordering of the manifest entries (the line order) is important.
I attempted to use IncludeResourceTransformer, but the below code produces the following error: "Error creating shaded jar: duplicate entry: META-INF/MANIFEST.MF".
<configuration> <shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>core</shadedClassifierName><createDependencyReducedPom>false</createDependencyReducedPom>
<minimizeJar>true</minimizeJar>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.IncludeResourceTransformer">
<resource>META-INF/MANIFEST.MF</resource>
<file>src/main/resources/META-INF/MANIFEST.MF</file>
</transformer>
</transformers>
</configuration>
The following pom configuration allows the programmer to replace the manifest file created by Apache Maven Shade plugin, with a custom manifest file. The custom manifest file should be placed in this directory in the maven project: "src/main/resources/META-INF/MANIFEST.MF"
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
...
<transformers>
<!-- Don't do this: Avoid adding anything that makes shade create or modify a manifest file.
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.mypackage.MyMainClass</mainClass>
</transformer>
-->
<!-- Add a transformer to exclude any other manifest files (possibly from dependencies). -->
<transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
<resource>MANIFEST.MF</resource>
</transformer>
<!-- Add a transformer to include your custom manifest file. -->
<transformer implementation="org.apache.maven.plugins.shade.resource.IncludeResourceTransformer">
<resource>META-INF/MANIFEST.MF</resource>
<file>src/main/resources/META-INF/MANIFEST.MF</file>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
I'm using the maven-shade-plugin to relocate some packages during the package phase of my build. I'm also using the maven-bundle-plugin to generate a manifest. The problem is the bundle plugin runs before the shade plugin (during the process-classes phase), and doesn't include any of my shaded packages in the generated manifest's exports.
How can I get these two plugins to play nice with each other, so that my relocated packages are treated like any other package by the bundle plugin?
--
By request, the Shade and bundle sections of my POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
<configuration>
<filters>
<filter>
<artifact>cglib:cglib</artifact>
<includes>
<include>net/sf/cglib/core/**</include>
<include>net/sf/cglib/proxy/**</include>
</includes>
</filter>
</filters>
<relocations>
<relocation>
<pattern>net.sf.cglib</pattern>
<shadedPattern>org.modelmapper.internal.cglib</shadedPattern>
</relocation>
<relocation>
<pattern>org.objectweb.asm</pattern>
<shadedPattern>org.modelmapper.internal.asm</shadedPattern>
</relocation>
</relocations>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Export-Package>
org.modelmapper,
org.modelmapper.builder,
org.modelmapper.config,
org.modelmapper.convention,
org.modelmapper.spi
</Export-Package>
<Private-Package>
org.modelmapper.internal.**
</Private-Package>
<Import-Package>
*
</Import-Package>
<Include-Resource>
{maven-resources},
{maven-dependencies}
</Include-Resource>
</instructions>
</configuration>
</plugin>
Taken from here
Another option is to dump maven bundle plugin altogether and use Maven Shade Plugin ManifestResourceTransformer to add the desired OSGI metadata to the manifest.
Take a look at xbean-asm-shaded/pom.xml for a example.
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<manifestEntries>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Export-Package>
org.apache.xbean.asm;org.modelmapper.builder; ...
</Export-Package>
<Import-Package>*</Import-Package>
<Private-Package>org.modelmapper.internal ...</Private-Package>
</manifestEntries>
</transformer>
Solution is very simple. You still can use maven-bundle-plugin and maven-shade-plugin at the same time. You just need to remember about the order. If you use bundle packaging maven bundle plugin will get executed during package phase before maven-shade. But that's not so wrong.
Here is the deal.
Use Private-Package: pkg.name.before.shading
Make maven-shade-plugin with one <include>null:null</include> - this will prevent shade plugin from creating empty jar
use maven-shade-plugin relocations - from pkg.name.before.shading to other.pkg.
You may see this trick working in FasterXML jackson-module-paranamer
I assume that after the compile phase is done you want to:
relocate some classes with the shade plugin
create a manifest with the bundle plugin
pack it all up with the jar plugin
The problem is the bundle plugin runs before the shade plugin
The bundle plugin is binded to process-classes phase which comes before the package phase to which the shade plugin is bound.
I suggest that you bind the shade plugin to process-classes phase also. Change shade plugin configuration like this:
<phase>process-classes</phase>
Since the shade plugin definition comes before the bundle plugin definition in the pom file, the shade plugin will run before the bundle plugin during the process-classes phase.
There is a neat transformer implementing just this functionality from Hazelcast - HazelcastManifestTransformer (ver 3.9). What it does is thoughtfully merging the Import-Package and Export-Package attributes, enabling the user to exclude extend/reduce the default merged result.
How to use it in your pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.1.0</version>
<dependencies>
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-build-utils</artifactId>
<version>3.9</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="com.hazelcast.buildutils.HazelcastManifestTransformer">
<mainClass>...</mainClass>
<!-- the tag below is required due to a missing null-check it seems -->
<overrideInstructions></overrideInstructions>
</configuration>
</executions>
</plugin>
The override instructions (Export/Import-Package) are comma delimited package names, preceded with an exclamation mark whenever we want to exclude those specific ones from the list.
Hope this helps! I do realize that's an old question, but seems the Hazelcast's transformer isn't gaining much publicity.