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
Related
Can you please suggest how to do plugin management in maven.
I have to call the below code
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<target>
<ant antfile="${basedir}/build/build.xml">
<target name="${ant.mode}" />
</ant>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
In some of the the submodule in a multi maven project module.
Can you suggest how to integrate this in only selective maven profiles?
Any Help will be appreciated .
Can some one suggest any solution for plugin management
You put the configuration into the parent into pluginManagement.
Either you specify the plugin (without configuration) in each module where you need it, or you use the skip parameter to activate/deactivate the plugin.
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>
I have a zip file in the path "C:\ptc\Windchill_10.1\Windchill" . Please can anyone tell me how to unzip this file using maven
Maven has a plugin to work with Ant. With that plugin you can create Ant-Tasks, this tasks are a sequence of xml instructions that you can use to (virtually) anything you need.
A piece of code that you can use as inspiration:
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>generate-resources</phase>
<configuration>
<tasks>
<echo message="unzipping file" />
<unzip src="output/inner.zip" dest="output/" />
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
source: https://ant.apache.org/manual/Tasks/unzip.html
Maven has a plugin named dependency plugin which helps you deal with artifacts, you can check documentation here
If your requirement is to unpack the dependencies and their transitive dependencies, take a look here
You can also take a look at solution provided in question here
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>
When deploying a webapp I need to update some variables in UI resources, unzip some assets and concat some files, currently this is achieved via an ant task. I'm trying to run this task in the maven build process using something like this...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>deploy-ui</id>
<phase>prepare-package</phase>
<inherited>false</inherited>
<configuration>
<target>
<property name="buildDir" value="${project.build.directory}/${project.build.finalName}" />
<ant antfile="build.xml" target="static-assets" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
The above fails because the files have not yet been copied into target directory. If I set the phase to "package" the ant task runs fine and all the files are created/amended, but it's no help as the .war has already been built before the ant target is run.
Basically, I need to run my ant target near the end of the prepare-package phase.
Having looked though the Lifecycle Reference I can't workout how to expose the more granular Goals to the antrun plugin.
Any ideas?
Since I did not get any answer on my comment I guess that you want to stay using maven-antrun-plugin.
From what I've learned and experienced, if two plugins are to be executed on the same phase, then they will be executed in the order they are declared in pom.xml.
For this to work you will have to add the maven-war-plugin in the <plugins/> list after the maven-antrun-plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>deploy-ui</id>
<phase>package</phase>
<inherited>false</inherited>
<configuration>
<target>
<property name="buildDir" value="${project.build.directory}/${project.build.finalName}" />
<ant antfile="build.xml" target="static-assets" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<!-- First step is to disable the default-war build step. -->
<id>default-war</id>
<phase>none</phase>
</execution>
<execution>
<!-- Second step is to create an exploded war. Done in prepare-package -->
<id>war-exploded</id>
<phase>prepare-package</phase>
<goals>
<goal>exploded</goal>
</goals>
</execution>
<execution>
<!-- Last step is to make sure that the war is built in the package phase -->
<id>custom-war</id>
<phase>package</phase>
<goals>
<goal>war</goal>
</goals>
</execution>
</executions>
</plugin>
Added some more executions so that the default-war is first disabled, then the war is exploded and lastly the war is packaged.
As you observed this is a place where the lifecycle doesn't provide the granularity needed. I answered a similar question for someone earlier. It's not an exact answer to your question but the technique may apply.