Every corporate pom is unique, so it's quite hard to talk about THE corporate pom.
A corporate pom might contain things like - licenses (or is this specified per project?) - distributionManagement - mailing lists - organization And it might contain predefined versions for plugins bound to the build-, clean- and site-lifecycle. It just depends on what is global enough for all projects. Just compare the corporate poms from apache[1] or codehaus[2] As you might see, codehaus doesn't predefine the plugin-versions here, that's done by its children. The settings.xml is not the right place to predefine versions, because a settings.xml is personal. When you define the prerequisites[3] in the pom or specify the requireMavenVersion enforcer-rule[4] you can ensure that at least a specific version of Maven is used. And that would also guarantee the versions of the plugins being used (as shown in the artifact-handlers.xml) -Robert [1] http://search.maven.org/#artifactdetails%7Corg.apache%7Capache%7C10%7Cpom [2] http://search.maven.org/#artifactdetails%7Corg.codehaus%7Ccodehaus-parent%7C4%7Cpom [3] http://maven.apache.org/ref/3.0.3/maven-model/maven.html#class_prerequisites [4] http://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html > Date: Sun, 25 Sep 2011 08:35:19 -0400 > From: [email protected]> To: [email protected] > CC: [email protected] > Subject: Re: Can I configure the version used as default for Maven plugins? > > 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<[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] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] che.org > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
