Envoyé de mon VT100 Phone
Le 25 sept. 2011 à 14:27, Baptiste MATHUS <[email protected]> a écrit : > 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. +1 Jeff > > 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 ! --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
