You're probably referring indirectly to this: https://github.com/apache/maven/blob/maven-3.5.1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L47-L49
Note the <releases> element: my understanding is this means that if you're using version 1.2.3 (and not 1.2.3-SNAPSHOT) of a plugin, then central will never be re-polled for the re-publishing of version 1.2.3 (which is exactly what you would and should expect). Probably what you should be using instead is a <pluginManagement> section in your pom.xml in question to pin the version of the sonar plugin to the version you want to be used. Best, Laird On Mon, Oct 2, 2017 at 12:19 PM Tom Golden <tgol...@andplus.com> wrote: > Wondering if someone can link me to some explicit documentation around the > update policy for plugin repositories. > > I ran into an issue today with our CI server where one build would use a > particularly old version of the sonar-maven-plugin. I eventually realized > after some digging that it was due to the contents of the > maven-metadata.xml file for the artifact. > > When I ran help:effective-pom on the project, I saw that the regular > repository element for Maven Central does not specify an update policy, but > the pluginRepository element for Central *does* specify it as *never*! > > I couldn't spot any official docs on this, and it doesn't appear that it's > set in the default %MAVEN_HOME%/conf/settings.xml. I also confirmed it > wasn't set that way in my ~/.m2/settings.xml, so it appears to be > hard-coded at some level in Maven itself. > > My question then is twofold. First, what's the rationale for having plugin > metadata go stale? Regular dependencies from Central don't act this way, > and it was very surprising. Second, what's the recommended approach here? > It's rare that I'm running a plugin that isn't specified directly in the > POM, so that "feels" like the right approach -- just specify a plugin > element in the project (or parent POM) for Sonar and it should work. That > also will work for all consumers of the project, versus recommending > changes to each user's settings.xml to override the update policy for > Central. Can anyone comment on that strategy? > > -- > Thanks, > Tom Golden >
