I have a WAR project that also produces some extra artefacts that I want to deploy to my artifact repo. So I have configured executions under the deploy plugin to deploy each of the extra artefacts
<execution>
<id>deploy-exe</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
<file>target/${project.build.finalName}.exe</file>
<packaging>exe</packaging>
<!-- pom, sources and javadoc already deployed by project. Release repo will fail redeployment -->
<generatePom>false</generatePom>
<sources/>
<javadoc/>
</configuration>
</execution>
But each execution will try and deploy the javadoc and sources for the project, even though I have tried to explicitly switch them off for the execution. NB I want javadoc and sources for the project, but I only want them deployed once (by deploy mojo).
This isn't a big deal until it comes to release time at which point my build breaks because it tries to deploy the javadoc and source for the deploy mojo as well as each of the deploy-file mojo executions to a release repo that doesn't allow redeploy of artifacts.
Is it possible to configure the maven-deploy-plugin to not deploy source & javadoc for the deploy-file mojo?
Related
My question is about saving artifacts into a repository. Especially, I am trying to upload into the Nexus Repository artifacts and release versions after the execution of a build pipeline for a Maven project (through Jenkins).
The only way that I want to do so, is just by using a pipeline written in Groovy so to integrate with Jenkins.
Note: I want the artifact version number to be always the same and the version number to change dynamically (not manually).
Is there a command or code generally which enables me to do that?
You are on the wrong level, this should happen in maven.
In pom.xml you need. (more here)
<distributionManagement>
<snapshotRepository>
<id>nexus-snapshots</id>
<url>http://localhost:8081/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
and then in the plugins section
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>default-deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
and you should be able to just do mvn clean deploy from your pipeline.
EDIT
There is another way with Nexus Artifact Uploader plugin
nexusArtifactUploader {
nexusVersion('nexus2')
protocol('http')
nexusUrl('localhost:8080/nexus')
groupId('sp.sd')
version("2.4.${env.BUILD_NUMBER}")
repository('NexusArtifactUploader')
credentialsId('44620c50-1589-4617-a677-7563985e46e1')
artifact {
artifactId('nexus-artifact-uploader')
type('jar')
classifier('debug')
file('nexus-artifact-uploader.jar')
}
artifact {
artifactId('nexus-artifact-uploader')
type('hpi')
classifier('debug')
file('nexus-artifact-uploader.hpi')
}
}
As #hakamairi already said, it is not recommended to re-upload artifacts with the same version to Nexus repository, Maven is built around the idea that an artifact's GAV always corresponds to a unique artifact.
However, if you want to allow re-deployment, you need to set the deployment policy of a release repository to "allow redeploy", then you can redeploy the same version. You cannot do that without allowing on repository side.
And for deploying to Nexus repo, you can use either Nexus Platform Plugin or Nexus Artifact Uploader.
ADDITIONAL SOLUTION THAT ALSO WORKS
I executed it manually and I exported the result of Nexus call. The result was the following command. This command need to be inserted inside the Jenkins pipeline as a Groovy code:
nexusPublisher nexusInstanceId: 'nexus', nexusRepositoryId: 'maven-play-ground', packages: [[$class: 'MavenPackage', mavenAssetList: [[classifier: '', extension: '', filePath: '**PATH_NAME_OF_THE_ARTIFACT**.jar']], mavenCoordinate: [artifactId: '**YOUR_CUSTOM_ARTIFACT_ID**', groupId: 'maven-play-ground', packaging: 'jar', version: '1.0']]], tagName: '**NAME_OF_THE_FILE_IN_THE_REPOSITORY**' }
In the field of filePath we need to insert the path and the name of the artifact.jar file.
In the field of artifactId we need to insert the custom (in this occasion for mine artifact) artifact id
In the field of tagName we need to insert the custom name of the directory from inside the Nexus Repository
This is a solution that can be done automatically without manual changes and edits. Once we have created the directory in Nexus repository this is going to be executed without any issue and without the need of changing the version number.
Note: also we need to enable re-deploy feature from inside the Nexus Repository settings.
I've started using travis-ci to automate my builds. I have several open source projects and they all deploy to nexus sonatype from where they go to maven central. They're all Java projects that use Maven to build and github as a repo.
I've been doing this manually for years and I have appropriate keys and logins and my pom is compatible etc.
Implementing the first one was easy enough, it is a single module project and it builds and deploys just fine. Then I did a second one, a multi module project and got that working in much the same way. My third, however, is baffling me.
The maven build on this thing is a bit tricky but it does run fine locally and I even have it running the actual build on travis successfully. But the deploy doesn't work.
The problem is that when it tries to connect to nexus sonatype I get an authorisation error:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project madura-bundles:
Failed to deploy artifacts: Could not transfer artifact nz.co.senanque:madura-bundles:pom:4.5.6 from/to sonatype-nexus-staging (https://oss.sonatype.org/service/local/staging/deploy/maven2/):
Failed to transfer file: https://oss.sonatype.org/service/local/staging/deploy/maven2/nz/co/senanque/madura-bundles/4.5.6/madura-bundles-4.5.6.pom.
Return code is: 401, ReasonPhrase: Unauthorized.
It looks like I have not set up my sonatype credentials correctly. But I have set it up the same way as I did for the other two projects. Specifically I go into Nexus Sonatype and get my Access User Token and add those to my environment (SONATYPE_USERNAME and SONATYPE_PASSWORD, I deleted both of these and re-entered them in case it was a typo). I also add references to those in my local maven settings file:
...
<server>
<id>ossrh</id>
<username>${env.SONATYPE_USERNAME}</username>
<password>${env.SONATYPE_PASSWORD}</password>
</server>
...
The local maven settings file is a file in my project and the .travis.yml maven commands refer to it. The travis.yml file has a deploy section identical to the other two (working) projects, except I have been adding extra bits to try and make it work. But none of the differences there look relevant. The working deploys look like this:
deploy:
provider: script
script: "mvn versions:set -DnewVersion=${TRAVIS_TAG} && mvn clean deploy -B -U -P release --settings travis/settings.xml"
on:
tags: true
so this is only going to kick off if the repo has been tagged and it uses the tag as the version number. In the other projects this works fine, but not in the one I'm trying to get working. The tag does trigger the deploy as it should, but the deploy fails.
Does anyone know why I get the deploy on one project but not another? Thanks for any help.
Okay, I figured it out. The problem is that the parent pom of the failing project does not have a release profile, the parent pom of the working project does have one. The release profile in both cases looks like this:
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.3</version>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://oss.sonatype.org/</nexusUrl>
<autoReleaseAfterClose>true</autoReleaseAfterClose>
</configuration>
</plugin>
</plugins>
</build>
</profile>
It is needed to sign the generated artifacts (jar files, javadoc files etc) with the gpg plugin and to deploy them to nexus. The deploy to nexus is attempted without this but because it didn't have the reference to serverId:ossrh it doesn't pick up credentials from the maven settings file and therefore I get an authorization error.
The release profile needs to be on the parent project and all the module projects. I had added it to the modules but forgot the parent.
I am running a dockerized Nexus Repository Manager v2.13.0-01. I have artifacts in the Snapshot repository that I want to remove using the Remove Snapshots scheduled task. My parameters for this scheduled task is as follows.
Repository/Group : Snapshots (Repo)
Minimum snapshot count: 1
Snapshot retention (days): 1
Remove if released : (unchecked)
Grace period after release (days): 1
Delete immediately: (checked)
When I run this task, I am expecting at least 1 snapshot to be kept and all other snapshots older than 1 day to be removed. What I am noticing when I am on the Browse Storage tab is that all the .jar + .pom files are being removed including associated .md5 and .sha1 files. For example, the following files are removed.
my-artifact-0.0.1-20160705-020817-5-javadoc.jar
my-artifact-0.0.1-20160705-020817-5-javadoc.jar.md5
my-artifact-0.0.1-20160705-020817-5-javadoc.jar.sha1
my-artifact-0.0.1-20160705-020817-5-sources.jar
my-artifact-0.0.1-20160705-020817-5-sources.jar.md5
my-artifact-0.0.1-20160705-020817-5-sources.jar.sha1
my-artifact-0.0.1-20160705-020817-5.pom
my-artifact-0.0.1-20160705-020817-5.pom.md5
my-artifact-0.0.1-20160705-020817-5.pom.sha1
my-artifact-0.0.1-20160705-020817-5.jar
my-artifact-0.0.1-20160705-020817-5.jar.md5
my-artifact-0.0.1-20160705-020817-5.jar.sha1
However, the associated .asc, .asc.md5, and .asc.sha1 hashes are NOT being removed. For example,
my-artifact-0.0.1-20160705-020817-5.jar.asc
my-artifact-0.0.1-20160705-020817-5.jar.asc.md5
my-artifact-0.0.1-20160705-020817-5.jar.asc.sha1
The following are the 2 maven plugins that I use to publish to my SNAPSHOT repository in the pom.xml.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.7</version>
<extensions>true</extensions>
<configuration>
<serverId>mycompanynexus</serverId>
<nexusUrl>http://nexus.mycompanynexus.io/</nexusUrl>
<autoReleaseAfterClose>true</autoReleaseAfterClose>
</configuration>
</plugin>
My distribution management section in the pom.xml looks like the following.
<distributionManagement>
<snapshotRepository>
<id>mycompanynexus</id>
<url>http://nexus.mycompanynexus.io/content/repositories/snapshots/</url>
</snapshotRepository>
<repository>
<id>mycompanynexus</id>
<url>http://nexus.mycompanynexus.io/content/repositories/releases/</url>
</repository>
</distributionManagement>
Not shown is my settings.xml where I supply the credentials for publishing to these repositories.
When I deploy, I simply type in mvn clean deploy with Maven v3.3.9.
As I was querying for solutions, I came across this blog post http://blog.sonatype.com/2010/01/how-to-generate-pgp-signatures-with-maven/, however, I don't know if I agree with not signing my SNAPSHOT artifacts (for if I didn't, then the GPG signatures and checksums would not be produced and I wouldn't have to worry about deleting them with the scheduled service). Moreover, OSSRH's guidelines illustrates signing SNAPSHOT artifacts. Maybe it is standard practice to NOT sign SNAPSHOT artifacts?
Any help is appreciated.
For internal usage of Nexus Repository Manager it is probably not standard practice to sign artifacts with GPG - not released and not snapshots either. However for distribution to the Central Repository via OSSRH it is pretty common although probably also not standard.
Typically the GPG plugin usage is part of a release profile and that is often not use for snapshot deployments. So depending on your internal needs you should be okay to just not use GPG at all or just not for snapshot builds.
On the other hands the snapshot deletion scheduled task should work for that deletion. There were some changes with regards to performance and behaviour in the last releases though. I just tested this and it turns out there is a regression in 2.11+. We created an issue at https://issues.sonatype.org/browse/NEXUS-10460 . Please follow that for updates. Hopefully we will include a fix in the next release (2.14).
Update 2016-07-13: A patch is now available and fixed jar is attached to the linked issue.
I have several Java projects that runs on several Jenkins jobs with Gradle and Jacoco plugins.
Let's say I have two jobs:
core
app
The core job, pulls from SVN to his workspace: /Jenkins_workspace/core/, then builds and then creates its jacoco exec file. It works fine and I can see the code coverage.
The app job, pulls from SVN to his workspace: /Jenkins_workspace/app/, then builds and then creates its jacoco exec file. It works fine and I can see the code coverage
However inside the app job there were some tests that actullay covered part of the core project. So the code coverage of the core job should be updated. I guess the core project should then have access to jacoco exec file of the app job, but they are on two different workspaces.
Question: How can the core job can access the jacoco exec file of the app job to update the core code coverage?
You can try to use both "destFile" and "append" configuration.
If you use maven:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-ut</id>
<phase>process-test-classes</phase>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<destFile>/path/to/jacoco.exec</destFile>
<append>true</append>
</configuration>
</execution>
</executions>
</plugin>
or gradle:
test {
jacoco {
append = true
destinationFile = file("/path/to/jacoco.exec")
}
}
Somehow the jacoco plugin does not allow searching for exec files outside of the current job workspace.
So what I did is, for every app build, its jacoco exec file is copied to the core workspace. The core job will then have no problem findind the jacoco exec file of the app job.
I am currently working on a multi-module project with the following structure.
root
-module A
-module B
What I want to do is to execute module B (The main method of the module) after the compiling of module B (Module B depends on module A). But I need to do this with a customized command.
Ex -
mvn runb
I know that the exec maven plugin can be used to run a project using maven. What I don't understand is how to create a custom command (phase) in maven. Is there anyway to achieve this without writing a maven plugin?
I referred various guides such as https://community.jboss.org/wiki/CreatingACustomLifecycleInMaven trying to achieve this. But they need to create components.xml and lifecycle.xml files under src/resources/META-INF. I don't understand how to apply that file structure to my project since it is a multi-module project where each module has seperate src directories.
(I'm using maven 3)
You cannot create a custom lifecycle without writing a Maven plugin.
And without hacking Maven itself, at least as of Maven 3.0.5, it is not possible to add a custom phase to Maven through a plugin. The phases are loaded up by the core of Maven from its configuration before any plugins are processed.
If you really have your heart set on using one command to do what you want, writing a plugin is the only way. With some pluginGroup mappings in your settings.xml, this can be made simpler (you can specify mvn my:plugin rather than mvn com.mygroupid:plugin).
But if you are willing to have a slightly more verbose syntax on the command line, what you want could be achieved through profiles and the exec maven plugin.
Add a profile to module B that uses the exec plugin to run itself.
Something like this:
<project>
...
<profiles>
<!-- This profile uses local webapp security instead of the BlueCoat device, useful for testing -->
<profile>
<id>execb</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>runb</id>
<goals>
<goal>java</goal>
</goals>
<phase>verify</phase> <!-- Anything after package phase -->
<configuration>
<!-- Exec plugin configuration goes here -->
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
You'll need to configure the exec plugin depending on how you run your JAR, more info here.
What this does is run the exec plugin as part of module B's build, but only if the execb profile is activated.
Now, when you just want to build your project (without any exec), build like normal (e.g. mvn install).
When you want to build and run, use the command line:
mvn install -Pexecb
and it will do the exec as part of the build.