Maven release plugin deploy issue - maven

My versions:
Maven 3.0.4
Jenkins 1.499
Nexus 2.2
maven-release-plugin 3.2
jdk 1.6
AIX 6.1
settings.xml
<server>
<id>snapshots</id>
<username>deploy</username>
<password>pass123</password>
</server>
<server>
<id>releases</id>
<username>deploy</username>
<password>pass123</password>
</server>
I have a lot of builds running in Jenkins which use the maven deploy plugin and upload artifacts to the Nexus repo. Since the same user is able to deploy snapshots we can eliminate user roles/permissions issue in Nexus. (I still gave admin role to this user for testing)
Company parent POM
<distributionManagement>
<repository>
<id>releases</id>
<url>http://myserver/repositories/releases</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>http://myserver/repositories/snapshots</url>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>
Project POM
<scm>
<connection>scm:svn:http://svnserver/tags/1.2.3</connection>
<developerConnection>scm:svn:http://svnserver/tags/1.2.3</developerConnection>
</scm>
I have confirmed the /target/checkout/ in the Jenkins workspace contains the latest POM. Also added <distributionManagement> inside the project POM
Now when I run maven release plugin from within Jenkins using mvn release:perform I am still getting this:
Deployment failed: repository element was not specified in the POM inside
distributionManagement element or in -DaltDeploymentRepository=id::layout
::url parameter
release:prepare shows no errors
The SVN tag gets created as expected
Then during deploy, it fails with the above error
Like I mentioned, snapshot deployment happens frequently and without error, so settings.xml, distributionManagement and Nexus permissions all seem to be in order.
I am able to access http://myserver/repositories/releases manually
I have checked with mvn help:effective-pom and mvn help:effective-settings and things seem to be in order
Any ideas ?

The error message is very explicit. There is NO distributionManagement in your POM. So you potentially are no inherting from the parent pom.
Run
mvn help:effective-pom
in the project you are trying to deploy and check. Or alternatively look at the effective POM in your IDE (Eclipse or whatever).
Then figure out the correct parent pom to use or potentially insert the distribtionManagement segment as desired.

Related

nexus-staging-maven-plugin returns 401 without information

I am working on getting Anonimatron available as libary in the central Maven Repository. In order to do that I followed the documentation in the sonatype documentation. The nexus staging plugin gives me a 401 error when running mvn deploy and I can't figure out why because it does not tell me what is going on.
I have a working account at oss.sonatype.org, and I have created a user access token there. The access token is stored in the servers section of my maven ~/.m2/settings.xml like so (token removed for reasons):
<servers>
<server>
<id>ossrh</id>
<username>USER_TOKEN</username>
<password>USER_PASSPHRASE</password>
</server>
</servers>
Then, in my maven https://github.com/realrolfje/anonimatron/blob/feature/anonimatron-as-library/pom.xml file I added the nexus staging plugin:
<distributionManagement>
<snapshotRepository>
<id>sonatype-snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
</snapshotRepository>
<repository>
<id>sonatype-release</id>
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2</url>
</repository>
</distributionManagement>
[...]
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.7</version>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://oss.sonatype.org/</nexusUrl>
<autoReleaseAfterClose>true</autoReleaseAfterClose>
</configuration>
</plugin>
When I run mvn deploy, I get the error:
[ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy (injected-nexus-deploy) on project anonimatron: Failed to deploy artifacts: Could not transfer artifact com.rolfje.anonimatron:anonimatron:jar:javadoc:1.9.3-20180512.204932-1 from/to sonatype-snapshots (https://oss.sonatype.org/content/repositories/snapshots): Failed to transfer file: https://oss.sonatype.org/content/repositories/snapshots/com/rolfje/anonimatron/anonimatron/1.9.3-SNAPSHOT/anonimatron-1.9.3-20180512.204932-1-javadoc.jar. Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
To check wether my token is indeed valid, I tried uploading with curl:
curl -u USER_TOKEN:USER_PASSPHRASE \
https://oss.sonatype.org/content/repositories/snapshots/com/rolfje/anonimatron/anonimatron/1.9.3-SNAPSHOT/anonimatron-1.9.3-20180512.093802-1-javadoc.jar \
--request PUT --data target/anonimatron-1.9.3-SNAPSHOT.jar
This succeeds and I can see the uploaded jar appear in the Nexus Repository Manager.
I have executed the same steps as in this question but since I have not uploaded anything yet, version numbers can not collide, although I did do a manual javadoc upload at the end. Since that is a snapshot, and it worked, I think my problem is with the nexus-staging-maven-plugin.
What I am searching for is a way to debug the nexus-staging-maven-plugin so that I know why it is failing. It does not tell me which credentials it is using, wether it loaded those from the settings.xml file, and what exact steps it is taking, even if I run mvn with -e and -X flags.
Executing a deploy with the standard maven-deploy plugin, as #khmarbaise mentioned, did seem to work. I reported this problem to sonatype as part of issues
OSSRH-39766 and OSSRH-39777.
Joel regenerated my permissions and now the nexus release plugin seems to be working. Note that this could also be caused by the maven-deploy which might have "primed" something.
All in all, the nexus release plugin could do with some improvements on the logging, particularly:
What profile is used to execute the steps
What step (exactly) is being executed
If there is a 401, tell which userid was used to execute that step and from which environment that was fetched (command line, settings.xml, etc).
I see some people struggling with the nexus plugin, while the plugin should actually make life easier.
Thanks to SonaType for the fast and helpful responses!
Add the following in your ~/.m2/settings.xml file:
<servers>
<server>
<id>ossrh</id>
<username>{YOUR_JIRA_USERNAME}</username>
<password>{YOUR_JIRA_PASSWORD}</password>
</server>
</servers>
Also, update your pom.xml:
<distributionManagement>
<snapshotRepository>
<id>ossrh</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
</snapshotRepository>
<repository>
<id>ossrh</id>
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</repository>
</distributionManagement>
Make sure repository id and server id matches.
In this example, the id is "ossrh".
Also, note that the username and password should be same as your jira login. That's it mvn clean deploy will now upload your jar to sonatype repoditory. Happy Deploying!!

Override URL to nexus repository specified in pom.xml

I have web project which I am going to deploy to nexus repository after successful build on jenkins. Currently in project in pom.xml I have following configuration as below where host and port to nexus repository is hardcoded:
<profiles>
<profile>
<id>deploy-snapshot</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<distributionManagement>
<snapshotRepository>
<id>snapshots</id>
<name>Repository for snapshots</name>
<url>http://ip1:port1/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
</profile>
</profiles>
My goal is override nexus url from jenkins without any changes in pom.xml, because currently that configuration in pom.xml is used on another environment which cannot be reconfigured.
It would be good to know in which way it can be done on jenkins taking into account that in future I am going to make similar for other job which will be in charge of deploying npm packages.
I've looked into following jenkins plugin https://wiki.jenkins.io/display/JENKINS/Nexus+Artifact+Uploader, but not sure that this one is actual one, also not sure that plugin will be good for zip archives for npm build.
That was requested in 2008(!) with Make the issue 295: "distributionManagement.site.url configurable from the command line"
In your case, check if passing the property altDeploymentRepository would help:
-DaltDeploymentRepository=...
More precisely, as in "Maven deploy:deploy using -DaltDeploymentRepository"
-DaltDeploymentRepository=releaseRepository::default::http://your.repo.url
"defaut" is the maven2 layout ("legacy" is for maven 1)
In order to overwrite it, you can set it in settings.xml file
In the version of Jenkins I'm using, which is ver. 1.602, if you configure your project as a Maven project, you can specify a "Deploy artifacts to Maven repostitory" post build action for which you can indicate the destination repository.

repository tag under distributionManagement vs repositories?

I see repository tag under parent element i.e distributionManagement and repositories. What's the difference ?
<distributionManagement>
<repository>
<id>...</id>
<name>...</name>
<url>...</url>
</repository>
</distributionManagement>
<repositories>
<repository>
<id>...</id>
<name>...</name>
<layout>default</layout>
<url>...</url>
</repository>
</repositories>
My understanding repository element under distributionManagement element specifies where it will deploy the artifacts at the time of deployment. It will come into picture only while mvn deploy i.e deployment time not during mvn install i.e build time. Right?
repository element under repositories element specifies from where dependencies needs to be picked up. It will come into picture only while mvn install not during mvn deploy. Right?
You have it exactly right!
From the POM reference:
Where as the repositories element specifies in the POM the location and manner in which Maven may download remote artifacts for use by the current project, distributionManagement specifies where (and how) this project will get to a remote repository when it is deployed. The repository elements will be used for snapshot distribution if the snapshotRepository is not defined.
Repositories declared under the distributionManagement element will be used for deployment, i.e. when running mvn deploy.
The repositories element will be used for downloading dependencies of the project. The command is not necessarily mvn install but any command that requires Maven to fetch artifacts from a repository.

Changing nexus servers: Maven deploy still deploys to old server

I have copied all contents from an old Nexus server to a new server. I am able to login to the new server, see all the uploaded artifacts, etc.
On the Jenkins build master, the maven builds are running obviously as the jenkins user. The home directory for that user is /var/lib/jenkins. Under there, I have copied the .m2 folder and changed all the old URL's in the settings.xml to point to the new URL.
However, when I run a maven deploy, while the build downloads some dependencies from the new nexus server, at the end of the build comes the mvn-deploy plugin and that tries to upload to the old server.
Do the artifacts, war, jar files have a record of the nexus server? Is there some setting in Jenkins that I'm missing? I did a grep for the old nexus address in /var/lib/jenkins folder and none of the config xml's have any mention of the old nexus.
Is the URL hardcoded in your pom? Maybe the pom is not using the params you set in the settings.xml?
The repositories configured in the settings.xml are the source of Maven artifacts. The destination for new artifacts is in the distributionManagement block. This is usually somewhere in your POM, or in a parent POM. The block will look something like the below. Chances are, the old URL is there.
<distributionManagement>
<repository>
<id>releases</id>
<name>Release Repository</name>
<url>${repository.url}/nexus/content/repositories/releases</url>
<layout>default</layout>
<uniqueVersion>true</uniqueVersion>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshot Repository</name>
<url>${repository.url}/nexus/content/repositories/snapshots</url>
<layout>default</layout>
<uniqueVersion>true</uniqueVersion>
</snapshotRepository>
</distributionManagement>

Local Nexus Repository Acting Like A Proxy For Some Maven Artifacts

I am using my own version of the Nexus web app repository installed on my local machine. I have Nexus configured with only one repository, the one where I store my snapshots:
http://localhost:8081/nexus/content/repositories/MySnapshots/
Note that after the Nexus installation I removed all the default repositories and added just my own. (Perhaps this was a bad idea?)
When I do a mvn clean install I noticed that some of the 3rd party artifacts are downloading straight from the remote repository. For example, here is one of the output lines from the build:
Downloading: http://repo.maven.apache.org/maven2/com/sun/org/apache/xml/internal/resolver/...
The strange thing is that I see other artifacts are going through my local Nexus to ultimately get to the artifact:
Downloading: http://localhost:8081/nexus/content/repositories/MySnapshots/org/apache/maven/wagon/wagon-provider-api...
Notice how the first part of the download url is my local repository but everything after MySnapshots is from apache.org.
It's almost like my Nexus repository is acting like a proxy to maven.apache.org for some artifact downloads but for others it goes straight to the source.
Can anyone tell me why this is happening?
I would't be bothered so much by this if all my builds succeeded all the time but sometimes, when I am compile large projects, I get build failures due to not being able to find an artifact.
For example, when I try to build another project that depends on eclipse jdt stuff I get the following error:
Downloading: http://localhost:8081/nexus/content/repositories/MySnapshots/eclipse/jdt/core/eclipse.jdt.core
Could not find artifact eclipse.jdt.core:eclipse.jdt.core
I am not sure if this means that my Nexus is not configured properly or if there really is no artifact eclipse.jdt.com. If the downloads were not going through my local Nexus repository I would then investigate the pom/settings.xml files. Instead this makes me wonder if it's due to my Nexus configuration.
If you would like to see my settings.xml for Maven and my pom file for the project I am building when I see this you can view them here:
settings.xml: http://pastebin.com/NvLr5bEA
pom.xml: http://pastebin.com/PJ0P3RaK
If you like to use the local nexus as a proxy as usual than you have to configure the settings.xml like this:
<mirrors>
<mirror>
<!--This sends everything else to /public -->
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://localhost:8081/nexus/content/groups/public</url>
</mirror>
</mirrors>
<profiles>
<profile>
<id>nexus</id>
<!--Enable snapshots for the built in central repo to direct -->
<!--all requests to nexus via the mirror -->
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<!--make the profile active all the time -->
<activeProfile>nexus</activeProfile>
</activeProfiles>
The tricky thing is the mirror thing which reroutes every call to the configured nexus instance.
Things you mentioned like eclipse parts can be problematic, cause only a few artifacts are available via maven central. Furthermore you should leave the defaults like maven central, release repository and the snapshots repository unchanged, cause these are the repository you need.
I don't think its a proxy issue , upto my understanding for the first case when it is downloading from Maven Central Repo , it might be possible that same artifact is not available in your nexus repository , that's why it is going to Maven Central Repo.
In the second case it is available in your nexus so reactor didn't try to download it from Maven Central Repo.

Resources