Brian E. Fox wrote:
>
> That was discussed in the thread I mentioned (below).
>
Thanks for those links Brian. As you say those threads have already come to
a conclusion about the explicit version. I guess this outcome has, however,
exposed a bug ( http://jira.codehaus.org/browse/MNG-3142 MNG-
In my opinion, yes. In my corporate builds, I lock down ALL versions of
plugins used by the lifecycles or bound in a pom.
-Original Message-
From: Casey Butterworth [mailto:[EMAIL PROTECTED]
Brian - would this approach hold true for all plugins (e.g. clean, compile,
install, etc
Brian E. Fox wrote:
>
> The best practice is to at least specify the versions in pluginManagement.
>
Brian - would this approach hold true for all plugins (e.g. clean, compile,
install, etc?)
--
View this message in context:
http://www.nabble.com/Should-all-plugins-have-an-explicit-version--
I recently raised issue http://jira.codehaus.org/browse/MNG-3142 MNG-3142
as there is a problem occuring when both a release and snapshot repo are
defined and contain different versions of the same plugin, and LATEST is
used as that plugin's version.
I'm wondering if the parent pom (or wherever
I can confirm that this is still happening in 2.0.6 and 2.0.7. However, the
issue is more substantial than originally thought, i.e. not only happening
for ranges but also for LATEST version transformation.
In our scenario, we are trying to resolve
org.codehaus.mojo:jaxb2-maven-plugin and have not
