maven: add arbitrary file as a servlet context resource - maven-2

I have a maven war project which produces webapp.war, and a maven 'skin' project which produces skin.zip (a file full of resources and XML files). Now I want to add this zip file as a servlet context resource (e.g WEB-INF/skin.zip).
I tried using overlays, but it expands the zip file into WEB-INF instead of placing the un-expanded file there:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<overlays>
<overlay>
<groupId>com.mycompany</groupId>
<artifactId>skin</artifactId>
<type>zip</type>
<targetPath>WEB-INF</targetPath>
</overlay>
</overlays>
</configuration>
</plugin>
Is there any way to prevent it from expanding the resource -- or somehow stick the file in there (without using ant-plugin).
Note: type is a totally unnecessary and unhelpful configuration element -- it does not tell the plugin how to expand the artifact, as you might expect -- it tells it how to FIND it. For example if you change type from zip to jar, it complains that it can't find the artifact (in the most unhelpful way possible).

I tried using overlays, but it expands the zip file into WEB-INF
Yes, that's what overlays do, the content is unpacked to be merged with the war. That's just not the right tool in your case.
Is there any way to prevent it from expanding the resource -- or somehow stick the file in there
I would use the Maven Dependency Plugin and its dependency:copy goal:
dependency:copy takes a list of artifacts defined in the plugin configuration section and copies them to a specified location, renaming them or stripping the version if desired. This goal can resolve the artifacts from remote repositories if they don't exist in local.
And bind it on the prepare-package phase. Below, some starting point:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-prepare-package</id>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.mycompany</groupId><!-- or ${project.groupId} -->
<artifactId>skin</artifactId>
<version>X.Y.Z</version><!-- or ${project.version} -->
<type>zip</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
See Copying specific artifacts for more examples.

Related

How can I add a specific jar only in a specific folder with Maven?

i have a maven project using the maven soapui plugin.
Unfortunately this one in my case need an external jar for jdbc for
some groovy scripts.
And according to their documentation, you have to add a repertory called "ext".
And after a dig in their code, this path is hardcoded in their plugin source.
You cant specify it.
So i have to add it directly to a subdirectory of MyProject :
Myproject/ext/postgresql.X.X.jar
I dont want to commit a jar in my project.
Is there a way to tell to maven to pickup a specific jar& add it to a specific directory ?
Thanks in advance for your answer.
You could use maven-dependency-plugin configured in your pom file to copy the artifact into that location during the generate-resources phase, something like this:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>copy-postgresql-artifact</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/ext</outputDirectory>
<!-- if you need to rename the jar -->
<destFileName>postgresql.X.X.jar</destFileName>
<artifactItems>
<artifactItem>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>X.X</version>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>

Copy dependencies maven war

When I try to use the plugin "maven-war-plugin", it copies all libraries to / WEB-INF/lib, how to copy to another directory? Example: "/ libtest"
I'm not sure to understand why you need to do this but I see two points here:
Avoiding dependencies to get copied into WEB-INF/lib (if not, then just skip the part related to 1.)
Getting them copied to another directory.
For 1. I'm assuming you need the dependencies (because you want to compile against them) but if you don't want the Maven War Plugin to copy them in WEB-INF/lib, you'll have to play with their scope, for example by declaring them as provided.
For 2. the Maven Dependency Plugin will be helpful here and I think you could use dependency:copy-dependencies, for example during the pre-package phase. Use it like this:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>pre-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<!-- configure the plugin here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
And configure the outputDirectory (and other parameters you could need).
Use the maven-dependency-plugin.

Maven - how can I add an arbitrary classpath entry to a jar?

I have an unusual situation where I need to add an arbitrary classpath entry (that points to a jar file) into the manifest of an executable jar. (This is for a Swing desktop application.)
The maven-jar-plugin generates the "Class-Path" entry for the jar manifest using the maven dependencies, and there doesn't appear to be any way of adding arbitrary entries.
I also looked at hard-coding the arbitrary classpath entry into the batch file that starts the application, using the "-classpath" parameter, but I can't figure out how to get Maven to filter the classpath into a batch file.
I found that there is an easy solution for this problem. You can add a <Class-Path> element to <manifestEntries> element, and set <addClassPath>true</addClassPath> to <manifest> element. So value of <Class-Path> element is added to class-path automatically. Example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addClasspath>true</addClasspath>
<mainClass>your.main.Class</mainClass>
</manifest>
<manifestEntries>
<Class-Path>../conf/</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>
Update: Here's how to filter a classpath into a custom manifest.
The maven-dependency-plugin's build-classpath goal can be configured to output the classpath to a file in the properties format (i.e. classpath=[classpath]). You then configure the filters element to use the generated classpath file, and configure the resources directory to be filtered.
For example:
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>build-classpath</goal>
</goals>
</execution>
</executions>
<configuration>
<outputFilterFile>true</outputFilterFile>
<outputFile>${project.build.directory}/classpath.properties</outputFile>
</configuration>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>
${project.build.outputDirectory}/META-INF/MANIFEST.MF
</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
<filters>
<filter>${project.build.directory}/classpath.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
Then specify the following in src/main/resources/META-INF/Manifest.MF:
Bundle-Version: 4.0.0
...
Classpath: ${classpath};[specify additional entries here]
Note: there is a bug with this processing using the standard window path separator (\), the generate path is stripped of separators (note it works fine on Linux). You can get the classpath to be generated correctly for Windows by specifying <fileSeparator>\\\\</fileSeparator> in the build-classpath goal's configuration.
You can customise the manifest in the jar-plugin's configuration. To do so you'd add something like this to your pom.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
...
<configuration>
<archive>
<index>true</index>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
<key>value</key>
</manifestEntries>
</archive>
</configuration>
...
</plugin>
The full archiver specification provides quite a few options. See the examples page for options on configuring the classpath.
If none of these work for you, you can define your own Manifest, set up properties containing the required entries and use a filter to populate the manifest with those properties
Try to do it like they do in this bug, i.e. merge entries using manifestEntries/Class-Path element
https://issues.apache.org/jira/browse/MJAR-41
I was able to get a slightly modified version of Rich Seller's approach working, avoiding the Error assembling JAR: Unable to read manifest file (line too long) issue that was mentioned in the comments.
I wanted to get all dependencies copied via the dependency-maven-plugin referenced in the .jar file's Manifest Class-Path. I could not use the <addClasspath>true</addClasspath> option of the Maven Jar Plugin as that put too much in my Jar Classpath (I'm only copying a selection of dependencies over).
Here's how I got this to work.
First I use the Maven Dependency Plugin to do the copying and at the same time build a classpath variable. Using the <outputProperty> I put this in a property rather than a file:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>copy-dependencies</goal>
<goal>build-classpath</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<!-- These properties are for build-classpath. It creates a classpath for the copied
dependencies and puts it in the ${distro.classpath} property. The jar Class-Path
uses spaces as separators. Unfortunately <pathSeparator> configuration property
does not work with a space as value, so the pathSeparator is set to a character
here and this is then replaced later using the regex-property plugin. -->
<prefix>lib</prefix>
<outputProperty>distro.classpath</outputProperty>
<pathSeparator>:</pathSeparator>
</configuration>
</execution>
</executions>
</plugin>
The syntax of the Jar Manifest Class-Path uses a space as separators. While the dependency plugin has a <pathSeparator> property, this one unfortunatly ignores the value if it is a space. So I just hardcode that one to some value and then use the build-helper-maven-plugin to replace it to that space I need:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<!-- Here the value of property for the jar the Class-Path is replaced to have a space
as separator. Unfortunately <replacement> does not work if a single space if specified
so this uses the surrounding .jar and lib to provide some content. -->
<name>distro.classpath.replaced</name>
<value>${distro.classpath}</value>
<regex>[.]jar[:]lib</regex>
<replacement>.jar lib</replacement>
</configuration>
</execution>
</executions>
</plugin>
Here, also the <replacement> value doesn't work if it's just a space, so I'm surrounding it with the text that exists around it.
Finally I can use the Maven Jar Plugin to pick up the property that was replaced with the space as separator. Because I pass the value of the classpath here in the maven definition (rather than picking it up from a filtered file) the line length constraints of the Manifest file will automatically be handled, and no 'line too long' problems appear:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<archive>
<manifest>
<mainClass>org.acme.Main</mainClass>
</manifest>
<manifestEntries>
<!-- Include the computed classpath with all copied dependencies in the jar here -->
<Class-Path>${distro.classpath.replaced}</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>

Maven-2: avoid default packaging?

My project uses many assemblies, hence I'm interested only in the assemblies.
On executing mvn install apart from the assemblies, I'm getting the default packaged .jar.
How can I avoid this?
I have a pom.xml similar to the one you have provided.
On executing mvn install, I'm getting App1.jar, App2.jar, and snapshot jar containing all contents
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-2</version>
<executions>
<execution>
<id>assemblyone</id>
<phase>compile</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>App1</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>${basedir}/src/main/resources/assemblies/report.xml</descriptor>
</descriptors>
</configuration>
</execution>
<execution>
<id>assemblytwo</id>
<phase>compile</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>App2</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>${basedir}/src/main/resources/assemblies/src.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
How can I avoid this snapshot (not sure of the exact term) jar and ensure that only assemblies are created?
I can read your question two ways, I've outlined answers for both below. If neither is correct, can you modify your question with a bit more explanation please.
1) Do you mean you have a project with default (jar) packaging, and you want to avoid the creation of the jar when no assembly is defined? If this is the case, what is the build achieving if no assembly is defined?
2) Do you instead mean that you are running mvn assembly:assembly to generate the assembly and want to know how to get that assembly when running the install goal?
For option 2, you can bind the assembly-plugin to a lifecycle phase to ensure it is always run, if you specify that <appendAssemblyId> should be false, then the assembly will replace the default jar.
For example, this configuration will invoke the assembly plugin during the packaging phase and replace the default jar:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/archive.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
For option 1, this is actually quite tricky to do. The best I can think of is to specify that the project has pom packaging and configure the project with the executions normally bound to the jar lifecycle in a profile. The lifecycle bindings you'd need to configure are listed in the introduction to the build lifecycle
I'm not sure that you can really do that in a really simple way.
A solution is to call the clean plugin once the build is achieved, by doing that:
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<executions>
<execution>
<id>auto-clean</id>
<phase>package</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
...
</build>
This way, the JAR created in the target/ directory will be deleted at the end of the Maven2 execution.
However, you will have to define another directory to store the assemblies created by Maven2. Otherwise, it will be deleted by the call of the clean plugin... If you want to store them in the directory assemblies-target/, you can add that in the pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-4</version>
<configuration>
...
<!-- Copy the ZIP in target/ of the ROOT directory. -->
<outputDirectory>assemblies-target</outputDirectory>
</configuration>
...
I think it would be much more clear if you showed us your whole POM and the artifacts that are being built. I can only guess as to what the problem is because your terminology is not what I am familiar with. This is my guess as to the problem: you have a POM configured to generated two assembly JARs, but you get a third JAR for the POM itself. In other words, if your POM's artifactId is MyApp, you are getting a MyApp-1.0.0.jar or similar in addition to the two JARs you actually want.
If that is the case, the problem boils down to that you are using Maven to create multiple artifacts from a single module. Maven is designed to produce only one primary artifact from each module. What I would do is change your POM to have a packaging type of "pom" and give it two modules in a <modules> section named App1 and App2. Create sub-directories under your module, one for each App. Give them each a POM configured for a single assembly, with a packaging type of "jar". Move the code/files/etc. as appropriate into each sub-module so there aren't any remaining in the parent module.
With Maven, if you find yourself generating two artifacts from one module (which you are), you should first consider that you are probably violating a Maven best-practice and rearrange things so you only produce one artifact per module.
Please let me know if this doesn't make sense and I will try to clarify.

Building a WAR project with unzipped JAR dependency?

I have two projects, my-lib and my-webapp. The first project is a dependency of my-webapp. Thus, when ask Maven2 to build my WAR, the my-lib JAR is added in the WEB-INF/lib/ directory of the web application.
However, I want to have the my-lib JAR unzipped directly in the WEB-INF/classes directory, exactly as if the my-lib sources were contained in the project my-webapp.
In others words, instead of having the following WAR content:
my-webapp/
...
WEB-INF/
lib/
my-lib-1.0.jar
... (others third libraries)
I want to have that:
my-webapp/
...
WEB-INF/
classes/
my-lib files
lib/
... (others third libraries)
Is there a way to configure the my-webapp or the Maven2 war plugin to achieve that?
As blaufish's answer says, you can use the maven-dependency-plugin's unpack mojo to unpack an artifact. However to avoid the jar appearing in WEB-INF/lib, you need to not specify it as a dependency, and instead configure the plugin to unpack specific artifacts.
The following configuration will unpack the contents of some.group.id:my-lib:1.0:jar into target/classes during the process-resources phase, even if the artifact is not defined as a dependency. Be careful when doing this though as there is potential to clobber your actual content, this can cause much debugging.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-my-lib</id>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>some.group.id</groupId>
<artifactId>my-lib</artifactId>
<version>1.0</version>
<type>jar</type>
<overWrite>false</overWrite>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
<overWriteReleases>false</overWriteReleases>
</configuration>
</execution>
</executions>
</plugin>
You can configure the maven-dependency-plugin to just do that, unpack instead of copying a jar as explained here.
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/alternateLocation</outputDirectory>
<destFileName>optional-new-name.jar</destFileName>
<includes>**/*.class,**/*.xml</includes>
<excludes>**/*test.class</excludes>
</artifactItem>
</artifactItems>
<includes>**/*.java</includes>
<excludes>**/*.properties</excludes>
<outputDirectory>${project.build.directory}/wars</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
The unpack mojo seems to be close to what you are aiming for. Not sure how to complete the entire flow you are proposing though.
(btw, I am doubtful if this a good idea. utility classes should go into jars, and the jars are put either in the WAR or io the EAR. Unpacking utility jars seems wrong)
I was able to use the unpack mojo as described above, plus I marked the dependency itself as "provided" (scope) to avoid duplicating the jar contents under WEB-INF/lib.
[Oops, just realized that you were using Maven. I don't delete this answer because it may come to the rescue of some Ant user. So there's no need to mod me down...]
How many times to I have to mention that Jar, War and Ear Ant tasks are subtasks of the Zip one? :-) If I remember correctly, something like this would do the trick:
<war dist="my-webapp.war">
<zipgroupfileset dir="libs" includes="*.jar" prefix="WEB-INF/classes"/>
</war>
Also worth a trial is with src="mylib.jar" but I haven't tested this option.