I'm using maven-shade-plugin to create an additional jar with all my dependencies. The shade phase is linked to the package phase, so my jar-with-dependencies is created everytime I do a mvn package.
However, I do not want this jar-with-dependencies to be deployed to Nexus during mvn deploy. How can I avoid this?
The best solution for such purpose is to put the maven-shade-plugin configuration into a profile which is not activated during the deploy phase.
Driven by the same necessity I've forked the maven-deploy-plugin plugin from GitHub doing changes in order to exclude a specific attached artifact from deploy as follow:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>3.0.0-SNAPSHOT</version>
<configuration>
<skipAttachedArtifacts>
<artifact>
<groupId>com.sample</groupId>
<artifactId>something</artifactId>
<version>${project.version}</version>
<packaging>jar</packaging>
<classifier>shaded</classifier>
</artifact>
</skipAttachedArtifacts>
</configuration>
</plugin>
Currently using the maven-deploy-plugin plugin with skip parameter set to true all artifacts are excluded from deploy while target here is to exclude only a specific one from the attached ones. On my fork I've introduced the skipAttachedArtifacts configuration parameter in order to specify attached artifacts to exclude from deploy.
Here is the link on my forked project on GitHub:
https://github.com/gregorycallea/maven-deploy-plugin
Here the link instead to the pull request I've submitted on apache plugin project:
https://github.com/apache/maven-deploy-plugin/pull/3
Related
tl;dr: I'm trying to solve this issue.
I have a project which builds a platform-dependent JAR and adds a classifier according to the os-maven-plugin:
<modelVersion>4.0.0</modelVersion>
<groupId>com.github.levyfan</groupId>
<artifactId>sentencepiece</artifactId>
<version>0.0.2</version>
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.6.1</version>
</extension>
</extensions>
<!-- ... -->
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<classifier>${os.detected.classifier}</classifier>
</configuration>
</plugin>
</plugins>
</build>
When I build and publish the artrifact with mvn --batch-mode deploy to GitHub Packages, I'm met with a conflict error. This is because the artifacts share a pom (sentencepiece-0.0.2.pom), but the JAR artifact is determined by the os-maven-plugin value (sentencepiece-0.0.2-XYZ.jar).
How can I inject this plugin-defined property at build-time to create unique artifact names?
Let me have a second try.
The items artifactId and version cannot be influenced by plugin generated properties. To influence them, the property must be given on the command line (or maybe in the POM directly).
So we are left with the classifier.
You need to build all artifacts with classifiers in the same build. So you need to change the build in a way that it builds for the different OS in one go. I don't know whether that is possible (depending on whether you can build e.g. for Windows on Linux) but it seems to be the only "Maven way" solution for you problem.
Of course, you could still try tricks like deleting the POM after you have deployed it, but if possible this should be avoided.
I want to deploy an application packaged in a jar to a wildfly server after maven package phase, and before maven install.
I am using the following plugin in the project pom.xml:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>2.1.0.Beta1</version>
<configuration>
<hostname>127.0.0.1</hostname>
<port>9990</port>
</configuration>
</plugin>
how to configure this plugin execution?
You need the deploy goal of that plugin. It accepts a filename parameter which you could use to specify the application archive that you want to deploy.
Binding this goal to the deploy phase of Maven will not override other goals being invoked in that phase of the Maven lifecycle. They will continue to run.
I have a multimodule project, and the last module being built is a distribution zip of the application.
core/
plugins/
plugins/logger
plugins/social
...
assemble/
I want to distribute the application in the form of Maven artifact. And I don't want to deploy the modules artifacts with it.
But the release plugin needs to run from the root (I want to do all the usual stuff like updating versions, tagging, commits these changes etc.)
What is the way to tell the release plugin which artifacts to deploy?
Note that this is different from limiting only the deploy plugin, because release plugin seems to call the deploy plugin in certain internal way. (Not sure about that.)
Seems like the Release plugin behavior was fixed and it now properly invokes deploy:deploy.
So I used my standard trick to suppress default plugin execution. Root pom.xml:
<!-- Don't deploy all artifacts. Overridden in submodules. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<executions> <execution> <id>default-deploy</id> <phase>none</phase> </execution></executions>
</plugin>
And the dist module pom.xml:
<!-- Enable deploy for this submodule. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<executions> <execution> <id>default-deploy</id> <phase>deploy</phase> </execution></executions>
</plugin>
The release:perform isn't doing that much magic. It checks out the code by the tag which was created during release:prepare. The default goal is 'deploy'. If you have specified a site within the distributionManagement of the pom.xml it'll be 'deploy site-deploy'. These steps could also be done by hand.
If you never want to deploy these artifacts (not during developerment nor release), I'd prefer the skip over using an undefined phase.
If this is only required during a release, you should specify this within a release-profile.
I have a Spring roo project (basically a maven project). I want to add dropbox sdk to the project, problem is it's not in maven. I added the following files
<dependency>
<groupId>com.dropbox</groupId>
<artifactId>dropbox-sdk</artifactId>
<version>1.3.1</version>
<scope>system</scope>
<systemPath>${project.basedir}/libs/dropbox-java-sdk-1.3.1.jar</systemPath>
</dependency>
It solved the compile error, but when i run the project, in Spring Tool Suite, the jar files are not added to war lib folder. How do I make maven add my external jar files to my the war lib folder?
I don't want to install the jar in maven since, I have to install it in all the machines that uses the project
I finally found a neat solution, which is a lot easier to implement. You add an in-project repository inside the java project and link to it in the pom.
You add an in-project repository in maven like this:
<repository>
<id>in-project</id>
<name>In Project Repo</name>
<url>file://${project.basedir}/libs</url>
</repository>
Then create a folder structure in the root folder of your project that looks something like this
/groupId/artifactId/version/artifactId-version.jar
and add the dependency as you would normally do.
This approach has the least amount of code and work required, and if that library ever gets add into a maven repository you can always remove your in-project repository.
There is a much easier solution, which is set webResource in the plugin. By the solution, you can add any files of your local disk to the war! A sample is as below,
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<warName>api</warName>
<webResources>
<resource>
<directory>libs/</directory>
<targetPath>WEB-INF/lib</targetPath>
<includes>
<include>**/*.jar</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
The best way to resolve this issue is to add these local jar files to WEB-INF/lib folder. You will find all these jars packaged in your final war file then.
I don't recommend this approach, but you could add some POM configuration to install the 3rd-party dependency in a separate profile:
<profiles>
<profile>
<id>install-dependencies</id>
<build>
<plugins>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>install-dropbox-sdk</id>
<phase>validate</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>com.dropbox</groupId>
<artifactId>dropbox-sdk</artifactId>
<version>1.3.1</version>
<file>src/main/lib/dropbox-java-sdk-1.3.1.jar</file>
<packaging>jar</packaging>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>build</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.dropbox</groupId>
<artifactId>dropbox-sdk</artifactId>
<version>1.3.1</version>
</dependency>
</dependencies>
</profile>
</profiles>
There are two profiles here: install-dependencies and build. The first installs the dropbox-sdk dependency into your Maven repository and needs to be run once on every machine as follows:
mvn -Pinstall-dependencies validate
The second is enabled by default, and adds the Dropbox SDK as a dependency.
To be honest though, this isn't much better than running
mvn install:install-file -Dfile=src/main/lib/dropbox-java-sdk-1.3.1.jar -DgroupId=com.dropbox -DartifactId=dropbox-sdk -Dversion=1.3.1 -Dpackaging=jar
on every machine.
The other downside of this approach is that you'll have to add all dependencies of the dropbox-sdk to your build as well- whereas if it is done properly by adding the JAR and a POM to a repository server, then Maven will calculate the transitive dependencies properly.
I recommend creating a "third party" repository in a Maven repository server such as Nexus or Artifactory, and uploading the jar to there. Even though that means putting the jar into Maven, at least with a repository server it is available to anyone who will be building your application.
change the lib path to :
src/main/webapp/WEB-INF/lib
in pom.xml:
<systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/xxxx.jar</systemPath>
The steps described in this site are pretty simple, and they work well enough:
https://mythinkpond.com/2010/10/02/adding-custom-jars-under-web-inflib-in-a-maven-project/
Create a “lib” folder under your project like this: “\src\main\webapp\WEB-INF\lib”
Copy needed “jars” etc that you want included inside your WAR bundle folder.
Invoke your maven build as you normally do. I use “mvn install”, which creates builds the war file.
I know I am really late but I was wondering on why you would not put in the jar in the local repo in the .m2 file and add a reference to the pom from there ?
I am writing a project for acceptance testing and for various reasons this is dependent on another project which is packaged as a WAR. I have managed to unpack the WAR using the maven-dependency-plugin, but I cannot get my project to include the unpacked WEB-INF/lib/*.jar and WEB-INF/classes/* to be included on the classpath so the build fails. Is there a way to include these files into the classpath, or is there a better way of depending on a WAR?
Many thanks.
There's another option since maven-war-plugin 2.1-alpha-2. In your WAR project:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
This creates a classes artifact which you can use in the acceptance tests project with:
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
</dependency>
Indeed, by design, Maven doesn't resolve transitive dependencies of a war declared as dependency of a project. There is actually an issue about that, MNG-1991, but it won't be solved in Maven 2.x and I'm not sure that I don't know if overlays allow to workaround this issue. My understanding of the suggested solution is to duplicate the dependencies, for example in a project of type pom.
(EDIT: After some more digging, I found something interesting in this thread that I'm quoting below:
I have been helping out with the development of the AppFuse project over
the last month where we make heavy use of the war overlay feature in the
Maven war plugin. It is a really nifty feature!
To get max power with war overlays I have developed the Warpath plugin
that allows projects to use war artifacts as fully fledged dependencies.
In brief:
1) The contents of the /WEB-INF/classes directory in the war dependency
artifacts can be included in the project's classpath for normal compile,
etc tasks.
2) Transitive dependencies from the war dependency artifacts become
available for use by other plugins, e.g. compile and ear - so no more
having to include all the dependencies when creating skinny wars!
The plugin has now been actively used in the AppFuse project for the
last few months, and I feel it is at a point where it is both usable and
stable.
Would the war plugin team be interested in including the warpath
functionality inside the war plugin? It would seem to be the most
natural place to host it.
So, I don't have any experience with it, but the maven warpath plugin actually looks nice and simple and is available in the central repo. To use it,include the following plugin configuration element in your pom.xml file:
[...]
<build>
<plugins>
<plugin>
<groupId>org.appfuse</groupId>
<artifactId>maven-warpath-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>add-classes</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
And add the war dependencies you want included in the classpath as warpath type dependencies:
[...]
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>warpath</type>
</dependency>
</dependencies>
[...]
Both the war and warpath dependency types are needed: the war type is used by the Maven war plugin to do the war overlay, the warpath type is used by the Warpath plugin to determine the correct list of artifacts for inclusion in the project classpath.
I'd give it a try.)
Use overlays. First, your test project need to have also packaging war.
Declare dependency of war project you want to test:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>your-project-arftifactId</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>test</scope>
</dependency>
then configure maven-war-plugin overlay:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webresources</directory>
<filtering>true</filtering>
</resource>
</webResources>
<overlays>
<overlay/>
<overlay>
<groupId>your.group</groupId>
<artifactId>your-project-artifactId</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
In the above example in test project I overwrite webresources configuration files (like conxtext etc.).
EDIT: This solution wasn't tested with Maven 3.
Good point, Justin. That got me actually solving my problem, namely: including a war into an assembly AND including all its transitive dependencies.
I could not duplicate the war-dependency as 'jar' as you suggested since the assembly plugin would not find a jar referenced by that groupId/artefactId, but
duplicating the war-dependency as type pom
works!
The war and its transitive dependencies are not included in the assembly.
To exclude the (now also appearing) pom file I had to add an exclude element like this:
<excludes>
<exclude>*:pom</exclude>
</excludes>
into my assembly.xml file.
I think this could also be a workaround for the original question of this thread.
If you list the dependency on the war project as a jar dependency it seems to pickup the required jars/resources. I'm using Maven 2.2 + m2eclipse.