Hi, I thought you were being ironic in your previous message. My answer was using the same kind of wording. I might have misread you though, if so please excuse me.
A corporate is nothing more than a POM that every projects of a company would inherit. It could be listed more visibly in some places, granted. Also read: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html Feel free to report an issue in the tracker about that. Cheers See http://www.sonatype.com/people/2008/05/misused-maven-terms-defined/ 2011/9/25 Andy Glick <andygl...@gmail.com> > I'm sorry to be so ignorant. Exactly how would I go about setting up a > corporate super pom and where is it documented? > > I have looked on the Maven website and in the Maven Complete Reference and > I have not noticed any explanation of this capability. > > > On 9/25/11 8:27 AM, Baptiste MATHUS wrote: > >> 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<andygl...@gmail.com> >> >> 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/****<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<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: pr...@jonand.se >>>>> To: users@maven.apache.org >>>>> 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<pr...@jonand.se> 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<pr...@jonand.se> >>>>>>>> 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<andygl...@gmail.com> >>>>>>>>>>> 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.**apac**he.org<http://apache.org> >>>>>>>>>>>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------****---------------------------- >>>>>>>>>>>> **--** >>>>>>>>>>>> >>>>>>>>>>> --------- >>>>>>>>>>> To unsubscribe, e-mail: >>>>>>>>>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>>>>>>>>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------****----------------------------* >>>>>>>>>>> *--** >>>>>>>>>>> >>>>>>>>>> --------- >>>>>>>> To unsubscribe, e-mail: >>>>>>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>>>>>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>>>>>>> > >>>>>>>> >>>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------****----------------------------** >>>>>>>> --** >>>>>>>> >>>>>>> --------- >>>>>> To unsubscribe, e-mail: >>>>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>>>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>>>>> > >>>>>> >>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------****----------------------------**--** >>>>> >>>> --------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>>> > >>>> >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>> <users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org> >>> > >>> >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
