hello, this is a new config or system. I installed Nexus 2.14.8, Jenkins 2.316, Maven 3.5.4. I use IDE Jboss Dev Studio. Jenkins issues the “maven clean deploy”, this is not issued anywhere else, no pom declarations for maven-deploy-plugin. Jenkins issues the deploy. I cannot get maven to do a deploy because it can’t find the plugin artifact. ? the maven deploy plugin 2.8.2 is available in the nexus repo under storage, however, each request to build or deploy calls the 2.7 maven deploy plugin, and it cannot be found, so the build fails.
maven simply gets what it expects, that is what it looks like. why will it not consume the 2.8.2 deploy plugin and continue to look for the 2.7 deploy plugin? Am I missing something in Maven or Nexus?
an install works ok, just can’t deploy. and I don’t really know what to expect? thanks!
If maven is forced to get a package it works. e.g. from Jenkins
clean package org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
then if finds the 2.8.2 and deploys, otherwise, a simple clean deploy looks for 2.7 plugin and it is not in the repo. I’m thinking this is a bug?
You have two things going on, both of which should be fixed.
My first question would be why is the latest version of maven trying to get a version of the deploy plugin that is 7 years old! Looks like the Apache guys are planning to update the defaults for Maven 3.6: https://issues.apache.org/jira/browse/MNG-6169.
I doubt it’s a bug, probably just a configuration error. The default 2.7 should work. Do you see Maven attempting to download 2.7? Is it downloading from your Nexus or from Central? If Nexus, do you see the request attempts in sonatype-work/nexus/logs/request.log?
As a matter of best practice, as you already found out, you can update this yourself by forcing maven to use the 2.8.2 version. To ensure reproducible builds it is a best practice to use the “pluginManagement” section of the pom to “pin” a version (Maven – Guide to Configuring Plug-ins). In your case, you would override the default 2.7 and put 2.8.2 in your pom.xml:
<!-- your groupId, artifactId, and other pom stuff are here-->
<!-- the rest of your build and plugin configuration-->
<!-- your dependency list and the rest of your pom stuff -->
hey thanks mworthington!
geese, wow! I don’t know? I don’t know why maven 3.5.4 is trying to download a deploy plugin 7 years old. It doesn’t make sense. I’m learning, I’m fairly newbie, and these types of questions are so hard to find answers to. Why ? IDK. I’m trying to learn.
yeah, I bet it is a config issue too. I do see maven attempting to download the 2.7 plugin. It is trying to get it from my Nexus public repo. however, this public repo is populated from several repos. One is the Maven Central Repo where these plugins are stored. Interestingly, and I don’t know what is going on here…
when I look in the Maven Central Repo, the Browse Index page has all the maven deploy plugins, also, the Browse Remote has them all, However, the Browse Storage ONLY has the maven deploy plugin 2.8.2 ??? why? I would think that the storage would replicate the Index or remote???
also, I don’t and can’t really put the plugin declaration in my POM. I don’t think. Because I am using Jenkins to do the build/deployment from Maven. so my POMS in Jboss Dev Studio projects do not reference a certain version for deployment plugins. I’m trying to find answer to… What determines the default plugins searched for or used? how does this work? is it by means of other plugin declarations like the following in POM? like the build-helper-maven-plugin or maven-resources-plugin ? would these determine other plugins maven looks for? AND THANK YOU SO MUCH!!!
The community is the perfect place to learn
Maven 3.5.4 has a set of default plugins and versions that it needs. And in this case, they just haven’t updated the default in 7 years. The “MNG” ticket I referenced in my previous reply contains a list of default plugins that they are planning to update for the next release of Maven. That Jira project is managed by the Apache group and committers to the Maven project. It is a good place to go if are having an issue with Maven itself. These two books have tons of good info as well: Maven: The Complete Reference (pdf) and Maven by Example (pdf)
You’re on the right track with browsing the repository content. You may have guessed by now that the different “Browse” tabs act differently. In the case of Central, Browse Remote and Browse Index should be the same and represent the full content of Central and should match what you see on https://search.maven.org. The Browse Storage tab contains only what your Nexus has downloaded from the remote site, which will be a very small subset of the remote site. More about these tabs and the rest of Nexus can be found in our Sonatype Docs.
It sounds like your Nexus instance has either not attempted to download the 2.7 version from Central, or that download failed for some reason. This KB article will help as well: Troubleshooting Artifact Download Failures – Sonatype Support. In particular, I use the ?describe method at the bottom of that page to see what Nexus is doing when downloading from a group repository. For example, take the “Downloading” URL from your Maven build output:
Downloading from nexus: http://your-nexus-servername:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-deploy-plugin/2.8.2/maven-deploy-plugin-2.8.2.jar
and add “?describe” on the end:
Under the “Response Outcome” heading, if it returns a “NOT FOUND (Item not found, core threw exception)” then the problem is in Nexus. If it returns a “FOUND (Item found and retrieved)”, it may be that Nexus just downloaded the 2.7 version and the problem is in Maven.
Thanks so much Michael !!! greatly appreciated! One day I hope to pay it forward too. You’re great! Have a great weekend!