And what would be the benefit of storing that information over using a corporate super-pom, which is the way to go to define corporate-wide versions to be used?
I don't think having things outside the build context is a good idea. Settings.xml is necessary, but it should stay as small as possible IMO, that is: basically almost only contain the corporate mrm address. Storing plugin versions outside the project itself would create a whirlwind of unreproducible issues, which were typical before maven 2.0.9. Cheers 2011/9/25 Andy Glick <[email protected]> > Robert, > > I believe that you have explained that the super pom or some important > aspects of it reside in artifact-handlers.xml and that if I were to modify > it and build a new version of Maven that I would have modified the super pom > and universally changed the version of a plugin available from the command > line without a pom in a manner that would be both controlled and repeatable? > > That is useful information, I appreciate the suggestion. Though it does > seem to me that this information is quite valuable and ought to be more > widely disseminated. > > Is it possible that this file, or some parts of it, could be exposed as a > public resource and available for configuration similar to settings.xml? > > > On 9/25/11 5:38 AM, Robert Scholte wrote: > >> 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<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: >>>>>>>>>> users-unsubscribe@maven.**apache.org<[email protected]> >>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> --------- >>>>>>>>> To unsubscribe, e-mail: >>>>>>>>> users-unsubscribe@maven.**apache.org<[email protected]> >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------**------------------------------** >>>>>> --------- >>>>>> To unsubscribe, e-mail: >>>>>> users-unsubscribe@maven.**apache.org<[email protected]> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@maven.**apache.org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>>> >>> ------------------------------**------------------------------** >> --------- >> To unsubscribe, e-mail: >> users-unsubscribe@maven.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
