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]
