That should be http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml?view=log
And here you see that the maven-deploy-plugin uses version 2.5 -Robert > Date: Sun, 25 Sep 2011 11:32:03 +0200 > From: [email protected] > To: [email protected] > Subject: Re: Can I configure the version used as default for Maven plugins? > > "To get what you want, just put a minimal pom.xml into the directory from > which you invoke your mvn goal and use pluginMgmt to bump the version" > > Thanks. This and the tip from Kristian, that the goal always is invoked > as<groupId>:<artifactId>:<version>:<goal>, seems to be the two choices to > configure the plugin version used and of them seems use of the qualified name > then often be the easiest choice. > > I understand the reason to why the default version of the plugins used not is > just updated every time, that seems wise, and as I understand it is it in the > pluginManagement of the super pom where the default version of plugins with a > prefix is configured. Just because I am a bit curious did I also have a look > at the super pom which I found should be located in the file > org/apache/maven/model/pom-4.0.0.xm in the JAR > lib/maven-model-builder-3.0.3.jar but I didn't find the configured plugin > versions there. Now it is only about curiosity : ) but where do I find this > configuration? > > Anyway, thanks for good information! It is interesting to learn these details > about Maven to better understand how it works. > > Jonny Andersson > > 2011-09-25 10:35, Stephen Connolly wrote: > > > The best practice for poms is to always specify a version of plugins. > > > > before Maven 2.0.8 the plugins used in the standard lifecycle did not > > have their version specified in the superpom that is baked into Maven > > itself. > > > > This meant that if a plugin was updated and cause a breakage for > > people, _everyone_ had the pain until they set the version explicitly. > > > > So from 2.0.9 onwards, Maven has included baked in versions for the > > plugins invoked by the baked in packaging's lifecycles. > > > > Every time there is a release of Maven, we typically bump up the > > versions to the next version that we think is stable. > > > > 3.0.x now has baked in warnings that you should specify the plugin > > version in your pom, that is so that at some stage, think 3.1.x or > > maybe 4.0.x we can remove the baked in versions _hack_ that was > > necessary to allow us to release versions of some critical core > > plugins (such as m-compiler-p) without fear of causing major issues > > for people who had not baked the version into their pom. > > > > The side-effect of all this is that if you are execution mvn plugin > > goals directly from the cli in a directory that does not have a > > pom.xml and you want to use a newer version, you need to call out the > > full long form of the plugin. > > > > To get what you want, just put a minimal pom.xml into the directory > > from which you invoke your mvn goal and use pluginMgmt to bump the > > version > > > > -Stephen > > > > On 25 September 2011 09:12, Jonny Andersson<[email protected]> wrote: > >> But it still seems strange to me that<prefix>:<goal> for the > >> maven-deploy-plugin always gives me version 2.5 (for Maven 3.0.3) and not > >> the newest available version 2.7. I also tried to delete version 2.5 from > >> my > >> local repo one time with version 2.7 left and tried again which caused > >> version 2.5 to be downloaded. What makes me confused is that I don't > >> understand where Maven 3.0.3 looks to see that it is version 2.5 that > >> should > >> be used every time. I have not tried but I guess this same version would be > >> used when invoked as part of a pom if not set explicitly. > >> > >> Jonny Andersson > >> > >> On 2011-09-25 10:05, kristian wrote: > >>> from the command-line without a pom.xml - yes you need to use the full > >>> plugin name > >>> <groupId>:<artifactId>:<version>:<goal> > >>> > >>> - Kristian > >>> > >>> On Sun, Sep 25, 2011 at 1:25 PM, Jonny Andersson<[email protected]> wrote: > >>>> I just remembered something I have read a while ago in "Maven: The > >>>> complete > >>>> reference" from Sonatype which partly answers my question ... The file > >>>> ~/.m2/repository/org/apache/maven/plugins/maven-metadata-central.xml is > >>>> where the prefix deploy is bound to maven-deploy-plugin and this could > >>>> bypassed with the explicit name of the plugin wanted like > >>>> org.apache.maven.plugins:maven-deploy-plugin. Of some reason is the group > >>>> id > >>>> not included in the prefix mapping and definitely not the version so it > >>>> does > >>>> not fully answer my question. well, a workaround is of course to always > >>>> use > >>>> the qualified name of the plugin with the version included when it is > >>>> invoked from the command line. > >>>> > >>>> Jonny Andersson > >>>> > >>>> On 2011-09-25 09:32, Jonny Andersson wrote: > >>>>> Thanks for your information. Use of pluginManagement in a parent pom to > >>>>> gain control over which plugins that are used seems to be a good advice. > >>>>> But > >>>>> I can't see how it could give control over which version of a plugin > >>>>> that is > >>>>> used when the goal for the plugin is invoked from the command line like > >>>>> the > >>>>> command mvn deploy:deploy-file ... But there seems to be somewhere > >>>>> configuration that decides that the default version used for that > >>>>> command > >>>>> should be 2.5, not the newest available version in the central > >>>>> repository, > >>>>> 2.7. > >>>>> > >>>>> Jonny Andersson > >>>>> > >>>>> On 2011-09-25 06:31, kristian wrote: > >>>>>> have a look at how it is done via > >>>>>> > >>>>>> mvn help:effective-pom > >>>>>> > >>>>>> - Kristian > >>>>>> > >>>>>> On Sat, Sep 24, 2011 at 4:54 PM, Andy Glick<[email protected]> > >>>>>> wrote: > >>>>>>> You would normally do this by using a pluginManagement tag in your pom > >>>>>>> and > >>>>>>> in that context declaring the plugin and setting the version to 2.7. > >>>>>>> This is > >>>>>>> particularly useful in a parent pom because the version will be > >>>>>>> inherited by > >>>>>>> all child poms. Then you would not include the version tag in the > >>>>>>> plugin > >>>>>>> declaration in the plugins tag. > >>>>>>> > >>>>>>> I think that it may be possible to configure this in a site super pom. > >>>>>>> > >>>>>>> On 9/24/11 6:22 AM, Jonny Andersson wrote: > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>> I have a question that I guess already have been asked somewhere but > >>>>>>>> I > >>>>>>>> have not been able to find the answer myself. The question came up > >>>>>>>> when > >>>>>>>> I > >>>>>>>> ran the command mvn deploy:deploy-file on the command line and found > >>>>>>>> that > >>>>>>>> the arg sources (given as -Dsources=...) wasn't recognized. It turned > >>>>>>>> out > >>>>>>>> that the command mvn deploy:deploy file always resolves to version > >>>>>>>> 2.5 > >>>>>>>> > >>>>>>>> mvn org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file > >>>>>>>> > >>>>>>>> where I would like it to resolve to resolve to version 2.7 > >>>>>>>> > >>>>>>>> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file > >>>>>>>> > >>>>>>>> as that version have the sources arg as an option so the question is, > >>>>>>>> is > >>>>>>>> it possible to configure which version of the plugin the unqualified > >>>>>>>> commands for a plugin like mvn deploy:deploy-file should resolve to? > >>>>>>>> > >>>>>>>> I use Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) in Win XP with > >>>>>>>> java > >>>>>>>> 1.6.0 > >>>>>>>> > >>>>>>>> Thanks for any information about this! > >>>>>>>> > >>>>>>>> Jonny Andersson > >>>>>>>> > >>>>>>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: [email protected] > >>>>>>> > >>>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
