maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste MATHUS ...@batmat.net>
Subject Re: Can I configure the version used as default for Maven plugins?
Date Sun, 25 Sep 2011 12:27:17 GMT
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 <andyglick@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/**
>> 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: pren1@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<pren1@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<pren1@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<andyglick@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.**apache.org<users-unsubscribe@maven.apache.org>
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  ------------------------------**------------------------------**
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message