Default update policy for plugin repositories is never?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Default update policy for plugin repositories is never?

Tom Golden
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
Reply | Threaded
Open this post in threaded view
|

Re: Default update policy for plugin repositories is never?

ljnelson
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 <[hidden email]> 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
>