I am trying to get maven to create the artifact jar with a custom MANIFEST.MF.
Sounds like an easy task using the following snippet:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>${project.build.directory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
Problem is, that the maven-jar-plugin still "messes" with the manifest I created manually. The documentation states
The content of your own manifest file will be merged with the entries
created by Maven Archiver
Unfortunately this is not the case for the Manifest-Version. It will always be set to "1.0". (I know that in theory this is correct, but for reasons I cannot influence, I need a different value in there).
Any ideas on how to step the jar plugin from touching my manifest at all or at least keeping its hands of the Manifest-Version?
I finally managed to solve my problem using the maven-antrun-plugin:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>package</phase>
<configuration>
<target>
<jar file="${project.build.directory}/${project.build.finalName}.jar" update="true" manifest="${project.build.directory}/META-INF/MANIFEST.MF" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
Related
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.
The problem is as follows: I need to generate files in META-INF so that registering using ServiceLoader works. FWIW, this is maven 3.0.4. The full link to the pom.xml file is here.
In order to generate these files, I use this plugin as follows:
<properties>
<serviceName>com.github.fge.msgsimple.serviceloader.MessageBundleProvider</serviceName>
</properties>
<!-- .... -->
<plugin>
<groupId>eu.somatik.serviceloader-maven-plugin</groupId>
<artifactId>serviceloader-maven-plugin</artifactId>
<version>1.0.2</version>
<configuration>
<services>
<param>${serviceName}</param>
</services>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
However, the generated file (META-INF/services/xxxx) don't find their way into the generated jar, so I have to resort to this (your eyes may bleed):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<property name="jarname"
value="${project.name}-${project.version}.jar"/>
<property name="victim"
value="${project.build.directory}/${jarname}"/>
<property name="serviceFile"
value="${project.build.directory}/classes/META-INF/services/${serviceName}"/>
<echo>${victim}</echo>
<echo>${serviceFile}</echo>
<jar destfile="${victim}" update="true">
<zipfileset file="${serviceFile}"
prefix="META-INF/services/"/>
</jar>
</target>
</configuration>
</execution>
</executions>
</plugin>
I am aware of the shade plugin. I have tried it, battled with it for hours on end, with no success at all. It just wouldn't include the file. The above is the only solution that works for me.
But this solution is not sustainable. I also want to generate jar with dependencies, and in this case the service file needs to be appended to; and the solution above only works for jars without dependencies...
So, what plugin would you need to make the whole thing work seamlessly? How do you configure it?
Have you considered the assembly plugin? I find it quite powerful.
http://maven.apache.org/plugins/maven-assembly-plugin/
An example:
https://gist.github.com/wytten/5782232
Dealing with a legacy project, I have the need to load text resources from a jar at an URL.
The text resources will be then filtered and included in the output; those resources come from a released artifact.
From resource-plugin I see it is only possible to give a number of directories; would it be possible to load resources as I need?
I want to do somthing like this, but using a remote jar instead of the oher project in the workspace:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
<resources>
<resource>
<directory>../<another project on the same workspace>/src/main/filtered-resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Remote resource plugin, as suggested in one of the answer doesn't work because no file from the imported bundle ends up in target; there is no way I can produce the original bundle using remote resource plugin (it's a legacy projetc still in use and completely out of my control).
I think the Maven Remote Resources Plugin will suit your needs.
EDIT:
Snippet obtained from the usage page of the plugin. That XML fragment will attach the plugin to the generate-sources phase (choose a different one if it doesn't fit your needs), will download the apache-jar-resource-bundle artifact and uncompress its contents into ${project.build.directory}/maven-shared-archive-resources.
For better results is recommended that the resources artifact had been created using the bundle goal of the same plugin.
<!-- Turn this into a lifecycle -->
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>process-remote-resources</id>
<phase>generate-sources</phase>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>org.apache:apache-jar-resource-bundle:1.0</resourceBundle>
</resourceBundles>
</configuration>
</execution>
</executions>
</plugin>
EDIT 2: Alternative Solution using AntRun
If your artifacts don't suit Maven needs and you need something more customized, then using AntRun plugin you could get it somehow:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>download-remote-resources</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<get src="URL of the resource" dest="${project.build.directory}" />
<unzip src="${project.build.directory}/filename.[jar|zip|war]" dest="${project.build.directory}/${project.build.finalName}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
I have a project expected to deliver a jar file:
<packaging>jar</packaging>
but the jar is built in a custom way, so the default packaging done with jar:jar has been disabled
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
but then when I want to apply shade:shade on the existing jar I get an error
The project main artifact does not exist.
I assume that maven doesn't know about the .jar file created by my custom tool. How to let it know, because antrun attachArtifact doesn't work
<attachartifact file="./bin/classes.jar" classifier="" type="jar"/>
the error I get is
An Ant BuildException has occured: org.apache.maven.artifact.InvalidArtifactRTException: For artifact {:jar}: An attached artifact must have a different ID than its corresponding main artifact.
So this is not the method to register main artifact... Is there any (without writing custom java plugin)?
Thanks,
Lukasz
I checked the sources of JarMojo and it gave me an idea how to solve it with Groovy (via gmaven)
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
and it works!:)
Something like this
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${basedir}/bin/classes.jar</file>
<type>jar</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
While your solution may work for a build to the install+ phase or where there are no dependencies in the reactor, in cases where only building to the compile or test phase the unpackaged classes won't be found by dependencies.
Building to compile happens when using plugins like the maven-release-plugin.
Extending your chosen solution to include identifying the unpacked classes during compile
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>set-main-artifact-compile</id>
<phase>compile</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes"))
</source>
</configuration>
</execution>
<execution>
<id>set-main-artifact</id>
<phase>package</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.artifact.setFile(new File("./bin/classes.jar"))
</source>
</configuration>
</execution>
</executions>
</plugin>
By default the maven-install-plugin will use the identified artifact along the lines of
${project.build.directory}/${project.finalname}.jar
So another option might go something like this
<build>
<directory>bin</directory>
<outputDirectory>bin/classes</outputDirectory>
<finalName>classes</finalName>
</build>
We were having the same problem, with getting the "attached artifact must have a different ID than its corresponding main artifact" error. We found the solution in the following excellent blog post:
embed-and-run-ant-tasks-and-scripts-from-maven
As detailed in this section, you can fix the problem by adding a classifier so Maven can distinguish between the ant-built jar and the maven-built jar. Since you're using antrun attachartifact, you'd need this:
<attachartifact file="./bin/classes.jar" classifier="foo" type="jar"/>
Note you'll also need to include that classifier (along with groupId, artifactId and version) whenever you want to grab this jar as a dependency in other projects.
I have a project that uses the maven-assembly-plugin to create source and binary tar and zip files for download. However, whenever I try to build the bin assembly it fails with an error that says "A tar file cannot include itself."
I can reproduce this problem with a minimal Maven project created with the maven-archetype-plugin and adding the following to the pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2</version>
<configuration>
<descriptorRefs>
<descriptorRef>src</descriptorRef>
<descriptorRef>bin</descriptorRef>
</descriptorRefs>
<outputDirectory>${project.build.directory}/site/downloads</outputDirectory>
</configuration>
<executions>
<execution>
<phase>site</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
With this plugin declaration in place I get the above-mentioned error message if I execute either "mvn site" or "mvn assembly:assembly".
Does anyone have any idea why this isn't working?
I'd be happy to provide any other information needed to help diagnose the problem.
It looks like there is a problem with version 2.2 of the Maven Assembly Plugin, your snippet works with the version 2.1 of the plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.1</version>
<configuration>
<descriptorRefs>
<descriptorRef>src</descriptorRef>
<descriptorRef>bin</descriptorRef>
</descriptorRefs>
<outputDirectory>${project.build.directory}/site/downloads</outputDirectory>
</configuration>
<executions>
<execution>
<phase>site</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
I didn't check Jira for an existing issue. If you can't find any, it would be nice to raise a new one.