I followed this tutorial to created a Maven build that can publish artifacts to Maven Central.
It works, and most of the tutorial is for authentication of some sort, so the only relevant part of it might just be:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>default-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
Now I wanted to only deploy two of the seven modules in total, so I added this to the parent POM:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
And <skip>false</skip> to the two modules I actually want to deploy.
This doesn't work. All modules get deployed.
I checked the effective POM, and it clearly shows skip=false for the two modules I want to deploy and skip=true for the other five modules.
Since deploying to Maven Central isn't really a reversible process, I don't want to trial and error my way through this problem, hence the question: How do I prevent Maven modules from deploying to Maven Central?
If you are deploying to Maven Central, it is the Nexus Staging Plugin that is doing the deployment instead of the Deploy plugin, so the configuration of the deploy plugin has no effect. To make the Nexus deploy plugin skip, set skipNexusStagingDeployMojo in its configuration to true.
For a complete example, you can look at one of my projects I deployed to Maven Central with the same problem - I want to deploy everything except the integration test modules.
In the parent POM, the Nexus deploy plugin is defined like normal as described in the tutorial (https://bitbucket.org/prunge/shoelaces/src/2347535282c9f5bb58d33cca22d9dd65c9db2c2b/pom.xml#pom.xml-200):
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.8</version>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://oss.sonatype.org/</nexusUrl>
<autoReleaseAfterClose>false</autoReleaseAfterClose>
</configuration>
</plugin>
and in the integration tests project (which itself has children that inherit this configuration) the staging plugin is skipped (https://bitbucket.org/prunge/shoelaces/src/2347535282c9f5bb58d33cca22d9dd65c9db2c2b/integration-tests/pom.xml#pom.xml-28):
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo>
</configuration>
</plugin>
This results in everything by default being deployed to Central except the integration tests project and everything underneath that.
Related
actually, I generate a maven site containing the documentation of my project. It works very well, in fact if works so well that my customers wants to get that site as a deliverable (for obvious documentation purpose).
How can I tell Maven to build a zip of the whole site and deploy it to my artifacts manager (Nexus)? I've tried several things, but if I understand correctly, deploying artifacts and generating the site are using different livecycle, and the site generation occurs after the deployment of the artifacts..
I could obviously get the generated site from the location it's deployed during site-deploy, but I would greatly appreciate an automatic and centralized way...
PS: giving access to the customer to our internal site is NOT an option.
Here is a working solution delegated to a Maven profile to isolate the behavior (and speed-up normal builds), but which could also be integrated in the default build if required (although not recommended).
<profiles>
<profile>
<id>site-zip</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.4</version>
<executions>
<execution>
<id>pack-site</id>
<phase>prepare-package</phase>
<goals>
<goal>site</goal>
<goal>jar</goal>
</goals>
<configuration>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>rename-file</id>
<phase>prepare-package</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${project.build.directory}/${project.build.finalName}-site.jar</sourceFile>
<destinationFile>${project.build.directory}/${project.build.finalName}-site.zip</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<goals>
<goal>attach-artifact</goal>
</goals>
<phase>package</phase>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}-site.zip</file>
<type>zip</type>
<classifier>site</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
What the profile is actually doing:
Configuring an execution of the Maven Site Plugin, attached to the prepare-package phase and running the site and jar goals (as also suggested by #khmarbaise).
Renaming the file from jar to zip via the Copy Rename Maven Plugin
Attaching the zip to the build via the Build Helper Maven Plugin and its attach-artifact goal
As such, running
mvn clean install -Psite-zip
Will also install in your local Maven cache the zipped site. The deploy phase would do the same on your target Maven repository then.
Note that the Maven Site Plugin and the Copy Plugin must be declared in the order above to follow the required flow within the same phase.
Also note that if zip is not a strong requirement, you can then just skip the Copy and Build Helper executions and only use the Maven Site execution. By default the jar created providing the site is already attached to the build (and hence it will be installed and deployed automatically). In order to have the zip, we had to disable this behavior (<attach>false</attach>) and re-attach it via the Build Helper plugin.
The generated zipped has automatically a classifier, which is site in this case.
You can use the maven-site-plugin.
After years of working with Spring, I'm working on a Java EE 7 application with EJB 3.2 and Maven. One thing I would like is to deploy the EJB Jars separately from the web application so I can develop independently. Including the EJB Jars in the WAR causes the app server to redefine the EJBs in the context of the WAR, which I don't want to happen.
The prescribed method is to have maven create a client jar with this directive:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
</plugin>
I'm excluding any Impls from the Client JAR.
The issue I'm having is that maven isn't installing the client jar during the install phase.
I can install it manually by doing this:
mvn install:install-file -Dfile=foo-1.0-client.jar -DgroupId=com.awesome -DartifactId=foo -Dversion=1.0 -Dpackaging=jar -Dclassifier=client
I fiddled around a lot and came up with this
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<ejbVersion>3.2</ejbVersion>
<generateClient>true</generateClient>
<clientExcludes>
<clientExclude>**/*Impl.class</clientExclude>
</clientExcludes>
</configuration>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<goals>
<goal>ejb</goal>
</goals>
</execution>
<execution>
<id>install</id>
<phase>install</phase>
</execution>
</executions>
</plugin>
</plugins>
However, this isn't proper. This installs the client as a new artifact, not as the same artifact with classifier client. When you include the client in another application, you are supposed to use ejb-client. This looks in your folder that contains the normal artifact, foo-1.0.jar, and looks for something with classifier client.
<dependency>
<groupId>com.awesome</groupId>
<artifactId>foo</artifactId>
<version>${com.awesome.version}</version>
<type>ejb-client</type>
</dependency>
Stumped here, any ideas?
I have a project which deploys to Maven Central via OSSRH using the Maven release and nexus-staging-maven plugins using the directions from http://central.sonatype.org/pages/ossrh-guide.html and http://central.sonatype.org/pages/apache-maven.html .
This works fine, but it often takes several hours for the artifact to be visible on Maven Central. Often we would like to make use of the deployed artifact immediately, so we end up deploying it from our local repositories to our internal Nexus server using deploy:deploy-file . This works but it is inelegant and easy to forget to do. Is there any way to make Maven deploy to an internal Nexus as well as Maven Central as part of the release process?
Note: This question is similar to, but not quite the same as, https://stackoverflow.com/questions/29019682/promote-artifact-from-internal-nexus-repository-to-maven-central
Add an additional execution to the maven-deploy-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>${maven.deploy.plugin.version}</version>
<executions>
<execution>
<id>nexus-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<altDeploymentRepository>yourNexusRepo</altDeploymentRepository>
</configuration>
</execution>
</executions>
</plugin>
The yourNexusRepo value will look something like this:
releases::default::https://nexus.host.org/nexus/content/repositories/releases
You should be able to get the exact URL from Nexus. The part before the first :: is the repository ID.
We solved this problem by no longer using nexus-staging-maven-plugin as an extension. This is described at https://help.sonatype.com/repomanager2/staging-releases/configuring-your-project-for-deployment :
If more control is desired over when the plugins deploy goal is
activated or if Maven 2 is used, you have to explicitly deactivate the
Maven Deploy plugin and replace the Maven Deploy plugin invocation
with the Nexus Staging Maven plugin...
In our case, we disabled the default-deploy execution by setting <phase>none</phase>. Our full solution is available at https://github.com/newmediaworks/nmw-oss-parent/commit/a7377a158feded473cb2f1618449e34173c22252 which includes an additional execution of maven-deploy-plugin in the jenkins-deploy profile.
The key takeaway follows, which so far seems to behave as if extension were enabled, but does not interfere with additional maven-deploy-plugin executions:
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId><artifactId>nexus-staging-maven-plugin</artifactId>
<!--
Not using as extension, since it blocks maven-deploy-plugin in the jenkins-deploy profile:
<extensions>true</extensions>
-->
<executions>
<execution>
<!-- Manually added since nexus-staging-maven-plugin is not used as extension -->
<id>default-deploy</id><phase>deploy</phase><goals><goal>deploy</goal></goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId><artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<!-- Manually disabled since nexus-staging-maven-plugin is not used as extension -->
<id>default-deploy</id><phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
For an android maven project (consisting out of a parent project that consists out of the main apk project and a test project), I would like to be able to use different plugin configurations for building the whole project.
I know that I can do this with profiles, but are there any other options?
The thing I would like to achieve is to execute a deploy with "mvn deploy" and to use a different plugin configuration, that should only be used if a deploy (or release) is taking place.
A concrete example would be to increase the android version code only if a deploy takes place. Binding the increase of the version code directly to the deploy phase does not work as the increased version code is needed before the process-resources phase to work properly.
I'm afraid maven profiles are your only option.
You could add an enforcer check on deploy phase to fail the build if a profile is not active:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>deploy</phase> <!-- enfoce rules on `mvn deploy` -->
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
<configuration>
<rules>
<requireActiveProfile>
<profiles>prod</profiles> <!-- require `-Pprod` -->
</requireActiveProfile>
</rules>
</configuration>
</plugin>
I am new to maven. I have product structure as following
myWebProduct
pom.xml
coreModule
webModule
htmlTestModule
The maven release plugin is defined at the company level of pom.xml file which is parent of myWebProduct. It has set release plugin run default goals of deploy and default preparationGoals clean verify install.
I want to release product in myWebProduct level which works fine except I would like to skip release the htmlTestModule. Because deploy life cycle on htmlTestModule will cause deployment of war file to remote Tomcat servers and I don’t want this happening during release.
I tried to add following in pom.xml of the htmlTestModule.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<skip>true</skip>
<preparationGoals>clean validate</preparationGoals>
<goals>testCompile</goals>
</configuration>
</plugin>
But when running 'mvn release:perform' at myWebProduct. I have seen the deploy goal was still executed on htmlTestModule. Could anyone help with this?
And I also tried following on htmlTestModule:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>donotRunMe</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
Still, the deploy goal always executed in htmlTestModule.
Thanks
I think you're taking the wrong approach here. Let me explain.
The deploy phase of maven is not meant to mean deploy to a remote server or anything like this. This is meant to be deploy to a remote repository.
Hence I believe you shouldn't try to skip the deploy phase in your module, but un-tie the deployment to a remote Tomcat server from the deploy phase, by making it a specific goal for example.