The dependency jar added to the assembly zip has "SNAPSHOT" version added to its name. Is there a way to get only version number from ${artifact.baseVersion} without SNAPSHOT ?
This is run inside maven-assembly-plugin. I would like the dependency to output like parent-2.0.jar instead of parent-2.0-SNAPSHOT.jar.
assembly.xml
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
<outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping>
<includes>
<include>www.example.com:parent:jar:2.0-SNAPSHOT</include>
</includes>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>
There's a few methods of doing this depending on your pipeline. The maven versions plugin can be used,
http://www.mojohaus.org/versions-maven-plugin/set-mojo.html
http://www.mojohaus.org/versions-maven-plugin/set-mojo.html#removeSnapshot
A configuration like this would do it,
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.4</version>
<configuration>
<newVersion>${project.version}</newVersion>
<allowSnapshots>false</allowSnapshots>
</configuration>
</plugin>
I'd recommend wrapping it in a profile and activate it only when required. This will update the project.version with in the POM. You can then commit it back to the repo, leave it as is etc. etc.
You may also want to look at the build helper plugin which can handle regex-ing properties etc. if the versions plugin doesn't meet your needs.
http://www.mojohaus.org/build-helper-maven-plugin/usage.html#
I cannot find a simple solution. So I have added new property ${client-version} and used it in assmebly.xml.
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<client-version>2.0</client-version>
</properties>
assembly.xml
<outputFileNameMapping>${artifact.artifactId}-${client-version}.${artifact.extension}</outputFileNameMapping>
Related
I am using maven-assembly plugin to create a jar of my application, including its dependencies as follows:
<assembly>
<id>macosx</id>
<formats>
<format>tar.gz</format>
<format>dir</format>
</formats>
<dependencySets>
<dependencySet>
<includes>
<include>*:jar</include>
</includes>
<outputDirectory>lib</outputDirectory>
</dependencySet>
</dependencySets>
</assembly>
(I omitted some other stuff that is not related to the question)
So far this has worked fine because it creates a lib directory with all dependencies. However, I recently added a new dependency whose scope is system, and it does not copy it to the lib output directory. i must be missing something basic here, so I call for help.
The dependency that I just added is:
<dependency>
<groupId>sourceforge.jchart2d</groupId>
<artifactId>jchart2d</artifactId>
<version>3.1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/external/jchart2d-3.1.0.jar</systemPath>
</dependency>
The only way I was able to include this dependency was by adding the following to the assembly element:
<files>
<file>
<source>external/jchart2d-3.1.0.jar</source>
<outputDirectory>lib</outputDirectory>
</file>
</files>
However, this forces me to change the pom and the assembly file whenever this jar is renamed, if ever. Also, it seems just wrong.
I have tried with <scope>runtime</scope> in the dependencySets and <include>sourceforge.jchart2d:jchart2d</include> with no luck.
So how do you include a system scoped jar to your assembly file in maven 2?
Thanks a lot
I'm not surprised that system scope dependencies are not added (after all, dependencies with a system scope must be explicitly provided by definition). Actually, if you really don't want to put that dependency in your local repository (for example because you want to distribute it as part of your project), this is what I would do:
I would put the dependency in a "file system repository" local to the project.
I would declare that repository in my pom.xml like this:
<repositories>
<repository>
<id>my</id>
<url>file://${basedir}/my-repo</url>
</repository>
</repositories>
I would just declare the artifact without the system scope, this is just a source of troubles:
<dependency>
<groupId>sourceforge.jchart2d</groupId>
<artifactId>jchart2d</artifactId>
<version>3.1.0</version>
</dependency>
I'm not 100% sure this will suit your needs but I think it's a better solution than using the system scope.
Update: I should have mentioned that in my original answer and I'm fixing it now. To install a third party library in the file-based repository, use install:install-file with the localRepositoryPath parameter:
mvn install:install-file -Dfile=<path-to-file> \
-DgroupId=<myGroup> \
-DartifactId=<myArtifactId> \
-Dversion=<myVersion> \
-Dpackaging=<myPackaging> \
-DlocalRepositoryPath=<path-to-my-repo>
You can paste this as is in a *nix shell. On windows, remove the "\" and put everything on a single line.
Btw you can automate it and make it a part of your maven build. The following will install your jar into your local repository before compilation:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>hack-binary</id>
<phase>validate</phase>
<configuration>
<file>${basedir}/lib/your-lib.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>your-group</groupId>
<artifactId>your-artifact</artifactId>
<version>0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
I find easy solution in case you creating jar
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
<directory>dependencies/mydep</directory>
<targetPath>WEB-INF/lib</targetPath>
<filtering>true</filtering>
<includes>
<include>**/*.jar</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
You can also handle this via adding a supplemental dependencySet in your dependencySets.
<dependencySet>
<scope>system</scope>
<includes>
<include>*:jar</include>
</includes>
<outputDirectory>lib</outputDirectory>
</dependencySet>
The best thing would be to use a Repository Manager (like Nexus, Artifactory, Archiva) and install this kind of dependency in a particular repository. After that you can use such things as a simple dependency. This will simplify your life.
Docs:
Edited: Sorry that i didn't realize alx also mentioned about the clean life cycle workaround.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>hack-binary</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/your-lib.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>your-group</groupId>
<artifactId>your-artifact</artifactId>
<version>0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
Base on the solution provided by alx, you can execute the install file step at clean phase. but since the clean phase is not in the default life cycle, you have to execute mvn clean at the first time to ensure the jar is ready in the local repo.
ex: mvn clean; mvn package
A simple solution for this is to add it into local maven repository
One way to do is via mvn install commands as suggested in previous post .
Another easy way is ,
1) In your eclipse ide right click on project select Maven option .
2) Select Install or deploy an artifact to a maven repository option and click on next.
3)Click on browse next to the Artifact file checkbox & select your jar file
4)Enter the GroupId and ArtifactId and version ensure generate pom & create checksum are checked & packaging is jar
Click on finish and that's it ! Your job is done the jar is added in your local repository which you can define in setting.xml or m2 directory
Now just add the simple maven dependency as per the GroupId,ArtifactId & jar version that you have entered as per the import and that's it your external jar will be packaged by maven.
it has worked in a easier way on my solution :
remove from your dependency :
<dependency>
<groupId>tiago.medici</groupId>
<artifactId>eureka</artifactId>
<version>0.0.1</version>
</dependency>
Then add the maven-install-plugin in the pom.xml as well.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>install-external</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/external/tiago.medici-0.0.1.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>tiago.medici</groupId>
<artifactId>eureka</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
I'm currently setting up a web project with maven 3.1.1 and maven war plugin 2.4 (http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html). In particular, I'm trying to copy and filter a resource with maven war plugin in a way that I've already done in the past and it worked. Here follows the relevant pom configuration:
WAR plugin configuration
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
...
<webResources>
<resource>
<directory>src/main/webapp/META-INF</directory>
<includes>
<include>**/*.xml</include>
</includes>
<filtering>true</filtering>
<targetPath>META-INF</targetPath>
</resource>
...
</configuration>
</plugin>
...
Activated profile definition:
...
<profiles>
<profile>
<id>dummyDev</id>
<build>
<filters>
<filter>filters/development.properties</filter>
</filters>
</build>
</profile>
...
META-INF/context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context reloadable="${tomcat.context.reloadable}">
</Context>
And finally "development.properties":
tomcat.context.reloadable=true
The context.xml gets copied into the WAR, but not filtered. If I try to write directly the property in the profile it works (i.e. without referencing to properties file): it doesn't work only when I reference thep properties file. It seems that there's something wrong in reading the properties file. Moreover, after having "packaged", maven doesn't tell me in the console that the properties file wasn't found (so maven finds the file).
Finally I tried to achieve the work with maven war plugin version 2.1.1 (and version 2.3) and it works: I tried more times just changing the maven war plugin's version so I'm pretty sure that the problem is that.
Am I missing something? Is this a known bug of maven war plugin? Am I trying to reach the result (filtering that file) in the right way? Thanks.
Well, I searched over maven war plugin jira's and foud out that this is actually a bug, introduced in version 2.4 (more at https://issues.apache.org/jira/browse/MWAR-301).
For convenience i quote the work-around pointed out in the jira issue:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
...
<filters>
<filter>${project.basedir}/src/main/filters/my-filter.properties</filter>
</filters>
</configuration>
</plugin>
Tried it on my skin and it works.
Anyway i note that if you specify a properties source file in this position (and this is pom-level war plugin declaration, not profile level), this will be read always, i.e. for every build profile you're specifying. Unless you re-declare the war plugin for each build profile and in each profile specify a different set of properties files (a really bad solution, pointed out here only to say that's wrong-way and for the sake of completeness, obviously IMHO), this solution is limited only to the case in which the given properties file must be always read no matter what build profile has been specified.
I have a multi-module project, where each module is packaged as an OSGi bundle using the Apache Felix maven-bundle-plugin. The whole project is built using a parent POM that lists the above-mentioned modules. Some modules contain configuration resources (e.g. .properties files) that should not be jarred inside the bundles for deployment but rather externalized in a dedicated config folder. My goal is to create a distribution folder (possibly, a zip file) that would look something like this:
my-app-distribution
/bundles
module1-bundle.jar
module2-bundle.jar
etc.
/conf
external1.properties
external2.properties
etc.
where the properties files under the /conf directory are hand-picked files from the individual modules' /target folders. The reason the .properties files need to be picked up from the target folders vs. the src folders is that I am using Maven resource filtering, and the source property files contain ${..} placeholders for environment-specific values. Those placeholders are properly resolved during the build process - per build profiles - and the target/ folders contain actual environment-specific values.
I've done such distribution file manipulations many times - for distributions with executable JARs, etc. In this case I wanted to use the "moduleSets" configuration of the assembly descriptor - it is easy to pull all binaries/jars into a single distribution folder using moduleSet/binary descriptor. It is also easy to exclude certain files from being packaged into an OSGi bundle - in the maven-bundle-plugin. The only issue I am stuck with is creating the /conf distribution folder and collecting the necessary properties files there. I have tried to use "fileSets" inside the "moduleSet/sources" descriptor to include only specific files from **/target of each module, but that didn't seem to work.
Anyone have a suggestion/advice? There's got to be an easy way. Or should I not use at all?
Thanks,
CV
#PetrKozelka I am not sure that extracting configuration files specific to different bundles into a separate module is a good idea. The whole point of OSGi is for bundles to be independent and potentially reusable - both in development and distributions. It only makes sense that - in the source code - the functionality implementation and related configuration files are grouped together. For a particular distribution though I might need to extract some of the files - if there is a requirement for admins to have control of certain parameters. That may be different for a different distribution/application. The assembly configuration may change, but the bundles/sources would stay the same. Also, each bundle may potentially be developed and used separately, not all bundles have to always be part of the same uber project - as you seem to assume. What you are suggesting seems to fall into the same old category of packaging enterprise applications by the type of artifacts (e.g. "model", "services", "dataaccess", "config" etc.), not by functional domain/features. Such approach works ok within a single application/project, but fails on the enterprise level where there is often a need to reuse subsets of vertical components (split by functional domains).
To your point of being dependent on the file layout in the modules, I agree that there should be no such dependency. Files could be hand-picked by their explicit name or naming convention - per very specific distro requirements. (Which is exactly the case I am facing.)
I have actually figured out how to do it more or less elegantly. Posting the solution below in case someone else is looking to solve a similar problem.
SUMMARY
I am using the maven-assembly-plugin to extract the binaries (bundle JARs) from the individual modules and package them in the <my-distribution-folder>/bundles directory. In each module where some resource files should be externalized, I consolidate such files under the /src/main/resources/external directory, and use maven-resources-plugin to copy those resources during the packaging phase to the auto-generated directory in my dedicated distribution module that contains the assembly.xml descriptor file and is also built as part of the top project. I use maven-clean-plugin in the parent POM to clear the contents of the distribution staging directory during the CLEAN phase of the top-level project build.
MAVEN CONFIGURATION
Inside each bundle's module POM that contains resources that need to be externalized I add the following resource management configuration:
<build>
<defaultGoal>install</defaultGoal>
<!--
enable resource filtering for resolving ${...} placeholders with environment-specific values
exclude any files that must be externalized
-->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>external/*.*</exclude>
</excludes>
</resource>
</resources>
...
<plugins>
<!-- Copies contents of resources/external to dedicated folder defined by property in parent -->
<!-- externalized resources will be packaged according to assembly instructions -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>
${project.parent.basedir}/${externalizableResourcesStageDir}
</outputDirectory>
<resources>
<resource>
<directory>src/main/resources/external</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<!-- builds a JAR file for this bundle -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Import-Package>*</Import-Package>
<Export-Package>
${project.groupId}.thismodulepackage*;version=${project.version}
</Export-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
where externalizableResourcesStageDir is a property defined in the top/parent POM. In the project, I include a special distribution module with the following structure:
distribution
/ext-resources (target auto-generated dir for external resources from modules)
/src
/assemble
assembly.xml (assembly descriptor)
The assembly.xml file looks like this:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>bin</id>
<!-- generate a ZIP distribution -->
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<baseDirectory>/</baseDirectory>
<moduleSets>
<moduleSet>
<!-- Enable access to all projects in the current multi-module build -->
<useAllReactorProjects>true</useAllReactorProjects>
<!-- select projects to include-->
<includes>
<include>myGroupId:myModuleArtifactId1</include>
<include>myGroupId:myModuleArtifactId2</include>
...
</includes>
<!-- place bundle jars under /bundles folder in dist directory -->
<binaries>
<outputDirectory>${artifactId}/bundles</outputDirectory>
<unpack>false</unpack>
</binaries>
</moduleSet>
</moduleSets>
<!-- now take files from ext-resources in this module and place them into dist /conf subfolder-->
<fileSets>
<fileSet>
<directory>ext-resources</directory>
<outputDirectory>${artifactId}/conf/</outputDirectory>
<includes>
<include>*</include>
</includes>
</fileSet>
</fileSets>
</assembly>
The distribution module's POM would look like this:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>myGroupId</groupId>
<artifactId>parentArtifactId</artifactId>
<version>...</version>
</parent>
<groupId>myGroupId</groupId>
<artifactId>distribution</artifactId>
<version>...</version>
<packaging>pom</packaging>
<name>Distribution</name>
<description>This module creates the <MyProject> Distribution Assembly</description>
<url>http:...</url>
<!-- NOTE: These dependency declarations are only required to sort this project to the
end of the line in the multi-module build.
-->
<dependencies>
<dependency>
<groupId>myGroupId</groupId>
<artifactId>myModuleArtifactId1</artifactId>
<version>${project.version}</version>
</dependency>
...
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>dist-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>src/assemble/assembly.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
The parent POM would list all the bundle modules, plus the distribution module and also define the assembly plugin:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>myGroupId</groupId>
<artifactId>myParentId</artifactId>
<version>...</version>
<packaging>pom</packaging>
<properties>
...
<!-- directory where build may place any sub-modules' resources that should be externalized -->
<!-- those resources may be picked up by maven-assembly-plugin and packaged properly for distribution -->
<externalizableResourcesStageDir>
esb-distribution/ext-resources
</externalizableResourcesStageDir>
</properties>
<!-- all project modules (OSGi bundles + distribution) -->
<modules>
<module>bundle-module1</module>
<module>bundle-module2</module>
...
<module>distribution</module>
</modules>
<dependencyManagement>
<dependencies>
...
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<!--
Cleans contents of the folder where the externalized resources will be consolidated
Each module adds its own external files to the distribution directory during its own build
-->
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>clean-ext-resources</id>
<phase>clean</phase>
</execution>
</executions>
<configuration>
<filesets>
<fileset>
<directory>${externalizableResourcesStageDir}</directory>
<includes>
<include>*.*</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<descriptors>
<descriptor>src/assemble/assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
NOTE: We've also made sure that the externalized resource files are excluded from being packaged inside the individual bundle JARs (see the resources section of the module POM.) The resulting unzipped distribution will look like this:
my-app-distribution
/bundles
module1-bundle.jar
module2-bundle.jar
etc.
/conf
external1.properties
external2.properties
etc.
Here is the scenario:
Two Maven 3 project builds.
Build 1 has snapshot jars that get deployed to Nexus.
Build 2 has dependencies on the snapshots, referenced like 1.0.0-SNAPSHOT, that gets packaged up and zipped up using the mvn clean package assembly:single command.
The issue that we run into:
Occasionally when the assembly is being created, the MANIFEST file for the jar will sometimes say some.jar.1.0.0-SNAPSHOT and sometimes it will say some.jar.1.0.0-datetime stamp, thus causing class not defined errors.
Is there a way to prevent this naming issue in the manifest file?
--edit--
Further research has discovered the following:
"If the snapshot was resolved from a repo then it will be timestamped,
if it came from the reactor or local repo, then it will be -SNAPSHOT.
The plugin calls into the maven resolution logic so this is core maven
behavior. "
This is the exact issue that is being run into. The 2nd build manifest file always has an entry of ./lib/Framework-1.0.0-SNAPSHOT.jar where as the actual jar file name changes between ./lib/Framework-1.0.0-SNAPSHOT.jar and ./lib/Framework-1.0.0-timestamp.jar based on the quote above.
In <dependencySet> you need to set <outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping>
for example:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>appserverB</id>
<formats>
<format>zip</format>
</formats>
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}</outputFileNameMapping>
<includes>
<include>application:logging</include>
<include>application:core</include>
<include>application:utils</include>
<include>application:appserverB</include>
</includes>
</dependencySet>
</dependencySets>
</assembly>
If you are using one of the built-in assembly descriptors you will need to replicate it for your self and add in the outputFileNameMapping entry yourself
For people who use maven-jar-plugin to create the artifact which is then packed by the maven-assembly-plugin and you still see timestamps in the classpath in artifact names, you can disable that by setting useUniqueVersions=false, as follows:
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin.version}</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>${project.build.finalName}.lib/</classpathPrefix>
<mainClass>com.nate.Application</mainClass>
<!-- To force the use of '-SNAPSHOT' version naming, simply disable the <useUniqueVersions> -->
<useUniqueVersions>false</useUniqueVersions>
</manifest>
<manifestEntries>
<buildTime>${maven.timestamp}</buildTime>
</manifestEntries>
</archive>
</configuration>
use <useBaseVersion>false</useBaseVersion>, when you need copy dependencies.
For example :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}</outputDirectory>
<useBaseVersion>false</useBaseVersion>
</configuration>
</execution>
</executions>
</plugin>
For those who run into this and see the answer from Stephen Connolly but still end up having exceptions, this might be due to the fact that some dependencies have classifiers in their names. Then you'll have to adapt the pattern to use the dashClassifier as an optional value:
<outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}</outputFileNameMapping>
This will work even if the dependecy used does not have a classifier.
See the documentation for the assembly plugin for further details.
<useBaseVersion>false</useBaseVersion> Did the trick for me. I just switched to a SNAPSHOT branch and it was including the timestamps.
Major advantage when using snapshots is one can refer to the actual date/time the snapshot was build.
When I create an executable jar with dependencies (using this guide), all properties files are packaged into that jar too. How to stop it from happening? Thanks.
UPDATE: I tried to exclude them using the Maven resources plugin, but then my application won't find the properties files when I run it in Eclipse (right click on the module -> Run As -> Java Application)
UPDATE: Thanks for your useful answers. I think I'd better spend time to learn Maven, for now I just choose the simplest solution.
To exclude any file from a jar / target directory you can use the <excludes> tag in your pom.xml file.
In the next example, all files with .properties extension will not be included:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>*.properties</exclude>
</excludes>
<filtering>false</filtering>
</resource>
</resources>
</build>
By convention, the directory src/main/resources contains the resources that will be used by the application. So Maven will include them in the final JAR.
Thus in your application, you will access them using the getResourceAsStream() method, as the resources are loaded in the classpath.
If you need to have them outside your application, do not store them in src/main/resources as they will be bundled by Maven. Of course, you can exclude them (using the link given by chkal) but it is better to create another directory (for example src/main/external-resources) in order to keep the conventions regarding the src/main/resources directory.
In the latter case, you will have to deliver the resources independently as your JAR file (this can be achieved by using the Assembly plugin). If you need to access them in your Eclipse environment, go to the Properties of your project, then in Java Build Path in Sources tab, add the folder (for example src/main/external-resources). Eclipse will then add this directory in the classpath.
This calls exactly for the using the Maven JAR Plugin
For example, if you want to exclude everything under src/test/resources/ from the final jar, put this:
<build>
<plugins>
<!-- configure JAR build -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<excludes>
<exclude>src/test/resources/**</exclude>
</excludes>
</configuration>
</plugin>
...
Files under src/test/resources/ will still be available on class-path, they just won't be in resulting JAR.
Put those properties files in src/test/resources. Files in src/test/resources are available within Eclipse automatically via eclipse:eclipse but will not be included in the packaged JAR by Maven.
Exclude specific pattern of file during creation of maven jar using maven-jar-plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3</version>
<configuration>
<excludes>
<exclude>**/*.properties</exclude>
<exclude>**/*.xml</exclude>
<exclude>**/*.exe</exclude>
<exclude>**/*.java</exclude>
<exclude>**/*.xls</exclude>
</excludes>
</configuration>
</plugin>
Do you mean to property files located in src/main/resources? Then you should exclude them using the maven-resource-plugin. See the following page for details:
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html
Another possibility is to use the Maven Shade Plugin, e.g. to exclude a logging properties file used only locally in your IDE:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>${maven-shade-plugin-version}</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>log4j2.xml</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
This will however exclude the files from every artifact, so it might not be feasible in every situation.
When I create an executable jar with dependencies (using this guide), all properties files are packaged into that jar too. How to stop it from happening? Thanks.
Properties files from where? Your main jar? Dependencies?
In the former case, putting resources under src/test/resources as suggested is probably the most straight forward and simplest option.
In the later case, you'll have to create a custom assembly descriptor with special excludes/exclude in the unpackOptions.
here is another solution to exclude all files in resources folder, the final configuration looks like:
<build>
<!-- exclude all files in resources-->
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>**/**</exclude>
</excludes>
<filtering>false</filtering>
</resource>
</resources>
<!-- other configurations/plugins in the pom.xml-->
</build>
or we can use includes to only package some file or folder.
But this method has a side effect. IDE will also exclude the resource files in target/classes folder. maven-jar-plugin only affect jar file.
I found a better solution to execludes resourses folder using maven-jar-plugin, here we use includes:
<build>
<plugins>
<!-- configure JAR build -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</plugin>
...