Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml

[Kasun Gajasinghe]

Hi,
I have a requirement where I need to specify specific versions for a
set of (basic) plugins. Adding the versions to the pom isn't an option
because we need to set the plugin versions for a vast number of
_unrelated_ builds.
As I've found at [1], I've manually created a plugin-registry.xml file
with needed plugin versions added. In addition to that, I've created
maven-metadata-local.xml file in the m2 repo under the plugin
directories, pointing to <latest> and <release> versions.

But, unfortunately, these specified versions were not picked up by
mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
always try to use 2.0.2. I've noticed that [1] is somewhat outdated
because --check-plugin-latest parameter doesn't available anymore. So,
I'm asking, does the plugin-registry.xml is still used by maven? If
not what is the mechanism for specifying specific plugin versions
(apart from current/parent pom)?

(I've seen in some posts that the plugin-registry.xml isn't used
anymore, but debug mode shows that mvn retrieves data from that file.
) Apparently, maven-metada-local.xml isn't created automatically for
me either. How I can instruct mvn to do that?

My plugin-registry.xml is at [2]. (There wasn't a template for that.
So, hope the format is correct!). maven-metadata-local.xml of
maven-compiler-plugin is at [3].
I'm using official apache maven-2.2.1 build.

Your help is much appreciated.

[1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
[2] http://pastebin.com/yprQU2D2
[3] http://pastebin.com/Y375dwMg

Thanks,
--Kasun

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Benson Margulies]

I don't know about plugin-registry.xml, but you can distribute a
settings.xml for use with -gs that has an active-by-default profile
with a pluginManagement section that does the job.

On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]> wrote:

> Hi,
> I have a requirement where I need to specify specific versions for a
> set of (basic) plugins. Adding the versions to the pom isn't an option
> because we need to set the plugin versions for a vast number of
> _unrelated_ builds.
> As I've found at [1], I've manually created a plugin-registry.xml file
> with needed plugin versions added. In addition to that, I've created
> maven-metadata-local.xml file in the m2 repo under the plugin
> directories, pointing to <latest> and <release> versions.
>
> But, unfortunately, these specified versions were not picked up by
> mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
> always try to use 2.0.2. I've noticed that [1] is somewhat outdated
> because --check-plugin-latest parameter doesn't available anymore. So,
> I'm asking, does the plugin-registry.xml is still used by maven? If
> not what is the mechanism for specifying specific plugin versions
> (apart from current/parent pom)?
>
> (I've seen in some posts that the plugin-registry.xml isn't used
> anymore, but debug mode shows that mvn retrieves data from that file.
> ) Apparently, maven-metada-local.xml isn't created automatically for
> me either. How I can instruct mvn to do that?
>
> My plugin-registry.xml is at [2]. (There wasn't a template for that.
> So, hope the format is correct!). maven-metadata-local.xml of
> maven-compiler-plugin is at [3].
> I'm using official apache maven-2.2.1 build.
>
> Your help is much appreciated.
>
> [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
> [2] http://pastebin.com/yprQU2D2
> [3] http://pastebin.com/Y375dwMg
>
> Thanks,
> --Kasun
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Damian Bradicich]

Why not define the pluginDependency section in a parent pom, then each of
your projects uses this as a parent, and pulls in all the plugin dep
versions defined in it (or overrides in project pom if necessary).  Seems
that would be simplest solution

Damian

On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <[hidden email]>wrote:

> I don't know about plugin-registry.xml, but you can distribute a
> settings.xml for use with -gs that has an active-by-default profile
> with a pluginManagement section that does the job.
>
> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
> wrote:
> > Hi,
> > I have a requirement where I need to specify specific versions for a
> > set of (basic) plugins. Adding the versions to the pom isn't an option
> > because we need to set the plugin versions for a vast number of
> > _unrelated_ builds.
> > As I've found at [1], I've manually created a plugin-registry.xml file
> > with needed plugin versions added. In addition to that, I've created
> > maven-metadata-local.xml file in the m2 repo under the plugin
> > directories, pointing to <latest> and <release> versions.
> >
> > But, unfortunately, these specified versions were not picked up by
> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
> > because --check-plugin-latest parameter doesn't available anymore. So,
> > I'm asking, does the plugin-registry.xml is still used by maven? If
> > not what is the mechanism for specifying specific plugin versions
> > (apart from current/parent pom)?
> >
> > (I've seen in some posts that the plugin-registry.xml isn't used
> > anymore, but debug mode shows that mvn retrieves data from that file.
> > ) Apparently, maven-metada-local.xml isn't created automatically for
> > me either. How I can instruct mvn to do that?
> >
> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
> > So, hope the format is correct!). maven-metadata-local.xml of
> > maven-compiler-plugin is at [3].
> > I'm using official apache maven-2.2.1 build.
> >
> > Your help is much appreciated.
> >
> > [1]
> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
> > [2] http://pastebin.com/yprQU2D2
> > [3] http://pastebin.com/Y375dwMg
> >
> > Thanks,
> > --Kasun
> >
> > --
> > ~~~*******'''''''''''''*******~~~
> > Kasun Gajasinghe,
> > University of Moratuwa,
> > Sri Lanka.
> > Blog: http://blog.kasunbg.org
> > Twitter: http://twitter.com/kasunbg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Damian Bradicich]

err...pluginManagement section even ;)

Damian

On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
<[hidden email]>wrote:

> Why not define the pluginDependency section in a parent pom, then each of
> your projects uses this as a parent, and pulls in all the plugin dep
> versions defined in it (or overrides in project pom if necessary).  Seems
> that would be simplest solution
>
> Damian
>
>
> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <[hidden email]>wrote:
>
>> I don't know about plugin-registry.xml, but you can distribute a
>> settings.xml for use with -gs that has an active-by-default profile
>> with a pluginManagement section that does the job.
>>
>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
>> wrote:
>> > Hi,
>> > I have a requirement where I need to specify specific versions for a
>> > set of (basic) plugins. Adding the versions to the pom isn't an option
>> > because we need to set the plugin versions for a vast number of
>> > _unrelated_ builds.
>> > As I've found at [1], I've manually created a plugin-registry.xml file
>> > with needed plugin versions added. In addition to that, I've created
>> > maven-metadata-local.xml file in the m2 repo under the plugin
>> > directories, pointing to <latest> and <release> versions.
>> >
>> > But, unfortunately, these specified versions were not picked up by
>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>> > because --check-plugin-latest parameter doesn't available anymore. So,
>> > I'm asking, does the plugin-registry.xml is still used by maven? If
>> > not what is the mechanism for specifying specific plugin versions
>> > (apart from current/parent pom)?
>> >
>> > (I've seen in some posts that the plugin-registry.xml isn't used
>> > anymore, but debug mode shows that mvn retrieves data from that file.
>> > ) Apparently, maven-metada-local.xml isn't created automatically for
>> > me either. How I can instruct mvn to do that?
>> >
>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
>> > So, hope the format is correct!). maven-metadata-local.xml of
>> > maven-compiler-plugin is at [3].
>> > I'm using official apache maven-2.2.1 build.
>> >
>> > Your help is much appreciated.
>> >
>> > [1]
>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>> > [2] http://pastebin.com/yprQU2D2
>> > [3] http://pastebin.com/Y375dwMg
>> >
>> > Thanks,
>> > --Kasun
>> >
>> > --
>> > ~~~*******'''''''''''''*******~~~
>> > Kasun Gajasinghe,
>> > University of Moratuwa,
>> > Sri Lanka.
>> > Blog: http://blog.kasunbg.org
>> > Twitter: http://twitter.com/kasunbg
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

[Kasun Gajasinghe]

On 25 Jul 2011, at 17:13, Benson Margulies <[hidden email]>  
wrote:

> I don't know about plugin-registry.xml, but you can distribute a
> settings.xml for use with -gs that has an active-by-default profile
> with a pluginManagement section that does the job.

Benson,
That would do the job though that's not exactly the need. We need the  
ability to specify the version per plugin, ie using maven-metadata.xml  
files under each plugin dir (in m2 repo.)
I should've more clear in the previous mail. What I've did was trying  
to activate maven-metadata.XML files by setting the <checkLatest> tag  
true in p-r.xml file. Plugin-registryxml then will only contain static  
plugin versions that will be overridden by maven-metadata.xml files.  
maven-metadata.xml thing should work, I'm missing something important!
The issue of using settings.xml is, settings.xml is owned by maven  
package. therefore the plugin-packages can't update the settings.xml  
file later on about the newly installed files. That comes in OS world  
I guess.

Thanks,
Kasun

Ps: Excuse for spelling mistakes, I'm sending this mail via mobile.  
Facts were not verified.

~~******~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka

>
> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe  
> <[hidden email]> wrote:
>> Hi,
>> I have a requirement where I need to specify specific versions for a
>> set of (basic) plugins. Adding the versions to the pom isn't an  
>> option
>> because we need to set the plugin versions for a vast number of
>> _unrelated_ builds.
>> As I've found at [1], I've manually created a plugin-registry.xml  
>> file
>> with needed plugin versions added. In addition to that, I've created
>> maven-metadata-local.xml file in the m2 repo under the plugin
>> directories, pointing to <latest> and <release> versions.
>>
>> But, unfortunately, these specified versions were not picked up by
>> mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>> always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>> because --check-plugin-latest parameter doesn't available anymore.  
>> So,
>> I'm asking, does the plugin-registry.xml is still used by maven? If
>> not what is the mechanism for specifying specific plugin versions
>> (apart from current/parent pom)?
>>
>> (I've seen in some posts that the plugin-registry.xml isn't used
>> anymore, but debug mode shows that mvn retrieves data from that file.
>> ) Apparently, maven-metada-local.xml isn't created automatically for
>> me either. How I can instruct mvn to do that?
>>
>> My plugin-registry.xml is at [2]. (There wasn't a template for that.
>> So, hope the format is correct!). maven-metadata-local.xml of
>> maven-compiler-plugin is at [3].
>> I'm using official apache maven-2.2.1 build.
>>
>> Your help is much appreciated.
>>
>> [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>> [2] http://pastebin.com/yprQU2D2
>> [3] http://pastebin.com/Y375dwMg
>>
>> Thanks,
>> --Kasun
>>
>> --
>> ~~~*******'''''''''''''*******~~~
>> Kasun Gajasinghe,
>> University of Moratuwa,
>> Sri Lanka.
>> Blog: http://blog.kasunbg.org
>> Twitter: http://twitter.com/kasunbg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kasun Gajasinghe]

On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
<[hidden email]> wrote:

> err...pluginManagement section even ;)
>
> Damian
>
> On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
> <[hidden email]>wrote:
>
>> Why not define the pluginDependency section in a parent pom, then each of
>> your projects uses this as a parent, and pulls in all the plugin dep
>> versions defined in it (or overrides in project pom if necessary).  Seems
>> that would be simplest solution

Since these projects are unrelated, they can't be glued together via a
parent pom.

Thanks,
--Kasun

>>
>> Damian
>>
>>
>> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <[hidden email]>wrote:
>>
>>> I don't know about plugin-registry.xml, but you can distribute a
>>> settings.xml for use with -gs that has an active-by-default profile
>>> with a pluginManagement section that does the job.
>>>
>>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
>>> wrote:
>>> > Hi,
>>> > I have a requirement where I need to specify specific versions for a
>>> > set of (basic) plugins. Adding the versions to the pom isn't an option
>>> > because we need to set the plugin versions for a vast number of
>>> > _unrelated_ builds.
>>> > As I've found at [1], I've manually created a plugin-registry.xml file
>>> > with needed plugin versions added. In addition to that, I've created
>>> > maven-metadata-local.xml file in the m2 repo under the plugin
>>> > directories, pointing to <latest> and <release> versions.
>>> >
>>> > But, unfortunately, these specified versions were not picked up by
>>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>>> > because --check-plugin-latest parameter doesn't available anymore. So,
>>> > I'm asking, does the plugin-registry.xml is still used by maven? If
>>> > not what is the mechanism for specifying specific plugin versions
>>> > (apart from current/parent pom)?
>>> >
>>> > (I've seen in some posts that the plugin-registry.xml isn't used
>>> > anymore, but debug mode shows that mvn retrieves data from that file.
>>> > ) Apparently, maven-metada-local.xml isn't created automatically for
>>> > me either. How I can instruct mvn to do that?
>>> >
>>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
>>> > So, hope the format is correct!). maven-metadata-local.xml of
>>> > maven-compiler-plugin is at [3].
>>> > I'm using official apache maven-2.2.1 build.
>>> >
>>> > Your help is much appreciated.
>>> >
>>> > [1]
>>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>>> > [2] http://pastebin.com/yprQU2D2
>>> > [3] http://pastebin.com/Y375dwMg
>>> >
>>> > Thanks,
>>> > --Kasun
>>> >
>>> > --
>>> > ~~~*******'''''''''''''*******~~~
>>> > Kasun Gajasinghe,
>>> > University of Moratuwa,
>>> > Sri Lanka.
>>> > Blog: http://blog.kasunbg.org
>>> > Twitter: http://twitter.com/kasunbg
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Damian Bradicich]

But why ?  simply have a top level parent pom that is solely for defining
your plugin versions (and anything else that may cover all of your
projects), you don't need any project specific logic in there.  The parent
doesn't need to list any of the children that use it (and act as an
aggregator), that is just a common use of a parent.

Damian

On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]>wrote:

> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
> <[hidden email]> wrote:
> > err...pluginManagement section even ;)
> >
> > Damian
> >
> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
> > <[hidden email]>wrote:
> >
> >> Why not define the pluginDependency section in a parent pom, then each
> of
> >> your projects uses this as a parent, and pulls in all the plugin dep
> >> versions defined in it (or overrides in project pom if necessary).
>  Seems
> >> that would be simplest solution
>
> Since these projects are unrelated, they can't be glued together via a
> parent pom.
>
> Thanks,
> --Kasun
>
> >>
> >> Damian
> >>
> >>
> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
> [hidden email]>wrote:
> >>
> >>> I don't know about plugin-registry.xml, but you can distribute a
> >>> settings.xml for use with -gs that has an active-by-default profile
> >>> with a pluginManagement section that does the job.
> >>>
> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
> >>> wrote:
> >>> > Hi,
> >>> > I have a requirement where I need to specify specific versions for a
> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
> option
> >>> > because we need to set the plugin versions for a vast number of
> >>> > _unrelated_ builds.
> >>> > As I've found at [1], I've manually created a plugin-registry.xml
> file
> >>> > with needed plugin versions added. In addition to that, I've created
> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
> >>> > directories, pointing to <latest> and <release> versions.
> >>> >
> >>> > But, unfortunately, these specified versions were not picked up by
> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
> >>> > because --check-plugin-latest parameter doesn't available anymore.
> So,
> >>> > I'm asking, does the plugin-registry.xml is still used by maven? If
> >>> > not what is the mechanism for specifying specific plugin versions
> >>> > (apart from current/parent pom)?
> >>> >
> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
> >>> > anymore, but debug mode shows that mvn retrieves data from that file.
> >>> > ) Apparently, maven-metada-local.xml isn't created automatically for
> >>> > me either. How I can instruct mvn to do that?
> >>> >
> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
> >>> > So, hope the format is correct!). maven-metadata-local.xml of
> >>> > maven-compiler-plugin is at [3].
> >>> > I'm using official apache maven-2.2.1 build.
> >>> >
> >>> > Your help is much appreciated.
> >>> >
> >>> > [1]
> >>>
> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
> >>> > [2] http://pastebin.com/yprQU2D2
> >>> > [3] http://pastebin.com/Y375dwMg
> >>> >
> >>> > Thanks,
> >>> > --Kasun
> >>> >
> >>> > --
> >>> > ~~~*******'''''''''''''*******~~~
> >>> > Kasun Gajasinghe,
> >>> > University of Moratuwa,
> >>> > Sri Lanka.
> >>> > Blog: http://blog.kasunbg.org
> >>> > Twitter: http://twitter.com/kasunbg
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: [hidden email]
> >>> > For additional commands, e-mail: [hidden email]
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
>
>
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Kasun Gajasinghe]

On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
<[hidden email]> wrote:
> But why ?  simply have a top level parent pom that is solely for defining
> your plugin versions (and anything else that may cover all of your
> projects), you don't need any project specific logic in there.  The parent
> doesn't need to list any of the children that use it (and act as an
> aggregator), that is just a common use of a parent.

This would not work because the parent-pom file you are saying will be
static. By static I meant that the parent pom file can not be modified
later on after it goes in to the m2 repo. So, when a need arise to add
a new plugin version, how it can be done?
The way to do this is by maintaining maven-metadata.xml files which
exists one per plugin under m2 repo (for example, for
maven-compiler-plugin, it's in
~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml).
This way, I don't have a problem when a new plugin is added to the
repo, right?

It doesn't really matter whether this can be done via
maven-metadata.xml or by some other means. We just need to make the
setting details file per-plugin.

--Kasun

>
> Damian
>
> On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]>wrote:
>
>> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
>> <[hidden email]> wrote:
>> > err...pluginManagement section even ;)
>> >
>> > Damian
>> >
>> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
>> > <[hidden email]>wrote:
>> >
>> >> Why not define the pluginDependency section in a parent pom, then each
>> of
>> >> your projects uses this as a parent, and pulls in all the plugin dep
>> >> versions defined in it (or overrides in project pom if necessary).
>>  Seems
>> >> that would be simplest solution
>>
>> Since these projects are unrelated, they can't be glued together via a
>> parent pom.
>>
>> Thanks,
>> --Kasun
>>
>> >>
>> >> Damian
>> >>
>> >>
>> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
>> [hidden email]>wrote:
>> >>
>> >>> I don't know about plugin-registry.xml, but you can distribute a
>> >>> settings.xml for use with -gs that has an active-by-default profile
>> >>> with a pluginManagement section that does the job.
>> >>>
>> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
>> >>> wrote:
>> >>> > Hi,
>> >>> > I have a requirement where I need to specify specific versions for a
>> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
>> option
>> >>> > because we need to set the plugin versions for a vast number of
>> >>> > _unrelated_ builds.
>> >>> > As I've found at [1], I've manually created a plugin-registry.xml
>> file
>> >>> > with needed plugin versions added. In addition to that, I've created
>> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
>> >>> > directories, pointing to <latest> and <release> versions.
>> >>> >
>> >>> > But, unfortunately, these specified versions were not picked up by
>> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>> >>> > because --check-plugin-latest parameter doesn't available anymore.
>> So,
>> >>> > I'm asking, does the plugin-registry.xml is still used by maven? If
>> >>> > not what is the mechanism for specifying specific plugin versions
>> >>> > (apart from current/parent pom)?
>> >>> >
>> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
>> >>> > anymore, but debug mode shows that mvn retrieves data from that file.
>> >>> > ) Apparently, maven-metada-local.xml isn't created automatically for
>> >>> > me either. How I can instruct mvn to do that?
>> >>> >
>> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
>> >>> > So, hope the format is correct!). maven-metadata-local.xml of
>> >>> > maven-compiler-plugin is at [3].
>> >>> > I'm using official apache maven-2.2.1 build.
>> >>> >
>> >>> > Your help is much appreciated.
>> >>> >
>> >>> > [1]
>> >>>
>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>> >>> > [2] http://pastebin.com/yprQU2D2
>> >>> > [3] http://pastebin.com/Y375dwMg
>> >>> >
>> >>> > Thanks,
>> >>> > --Kasun
>> >>> >
>> >>> > --
>> >>> > ~~~*******'''''''''''''*******~~~
>> >>> > Kasun Gajasinghe,
>> >>> > University of Moratuwa,
>> >>> > Sri Lanka.
>> >>> > Blog: http://blog.kasunbg.org
>> >>> > Twitter: http://twitter.com/kasunbg
>> >>> >
>> >>> > ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: [hidden email]
>> >>> > For additional commands, e-mail: [hidden email]
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> ~~~*******'''''''''''''*******~~~
>> Kasun Gajasinghe,
>> University of Moratuwa,
>> Sri Lanka.
>> Blog: http://blog.kasunbg.org
>> Twitter: http://twitter.com/kasunbg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Benson Margulies]

As a general principle, the design of maven is trending toward locking
down the versions of plugins for a build. Otherwise, you can't grab an
old version of the source from a tag and depend on building it.

Therefore, the idea of a separate 'control panel' for plugin versions
is not popular. Global settings.xml is about the best you are going to
do. Some day, conceivably, even that might stop working, but don't
lose sleep over it.

On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe <[hidden email]> wrote:

> On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
> <[hidden email]> wrote:
>> But why ?  simply have a top level parent pom that is solely for defining
>> your plugin versions (and anything else that may cover all of your
>> projects), you don't need any project specific logic in there.  The parent
>> doesn't need to list any of the children that use it (and act as an
>> aggregator), that is just a common use of a parent.
>
> This would not work because the parent-pom file you are saying will be
> static. By static I meant that the parent pom file can not be modified
> later on after it goes in to the m2 repo. So, when a need arise to add
> a new plugin version, how it can be done?
> The way to do this is by maintaining maven-metadata.xml files which
> exists one per plugin under m2 repo (for example, for
> maven-compiler-plugin, it's in
> ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml).
> This way, I don't have a problem when a new plugin is added to the
> repo, right?
>
> It doesn't really matter whether this can be done via
> maven-metadata.xml or by some other means. We just need to make the
> setting details file per-plugin.
>
> --Kasun
>
>>
>> Damian
>>
>> On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]>wrote:
>>
>>> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
>>> <[hidden email]> wrote:
>>> > err...pluginManagement section even ;)
>>> >
>>> > Damian
>>> >
>>> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
>>> > <[hidden email]>wrote:
>>> >
>>> >> Why not define the pluginDependency section in a parent pom, then each
>>> of
>>> >> your projects uses this as a parent, and pulls in all the plugin dep
>>> >> versions defined in it (or overrides in project pom if necessary).
>>>  Seems
>>> >> that would be simplest solution
>>>
>>> Since these projects are unrelated, they can't be glued together via a
>>> parent pom.
>>>
>>> Thanks,
>>> --Kasun
>>>
>>> >>
>>> >> Damian
>>> >>
>>> >>
>>> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
>>> [hidden email]>wrote:
>>> >>
>>> >>> I don't know about plugin-registry.xml, but you can distribute a
>>> >>> settings.xml for use with -gs that has an active-by-default profile
>>> >>> with a pluginManagement section that does the job.
>>> >>>
>>> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> > I have a requirement where I need to specify specific versions for a
>>> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
>>> option
>>> >>> > because we need to set the plugin versions for a vast number of
>>> >>> > _unrelated_ builds.
>>> >>> > As I've found at [1], I've manually created a plugin-registry.xml
>>> file
>>> >>> > with needed plugin versions added. In addition to that, I've created
>>> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
>>> >>> > directories, pointing to <latest> and <release> versions.
>>> >>> >
>>> >>> > But, unfortunately, these specified versions were not picked up by
>>> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>>> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>>> >>> > because --check-plugin-latest parameter doesn't available anymore.
>>> So,
>>> >>> > I'm asking, does the plugin-registry.xml is still used by maven? If
>>> >>> > not what is the mechanism for specifying specific plugin versions
>>> >>> > (apart from current/parent pom)?
>>> >>> >
>>> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
>>> >>> > anymore, but debug mode shows that mvn retrieves data from that file.
>>> >>> > ) Apparently, maven-metada-local.xml isn't created automatically for
>>> >>> > me either. How I can instruct mvn to do that?
>>> >>> >
>>> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
>>> >>> > So, hope the format is correct!). maven-metadata-local.xml of
>>> >>> > maven-compiler-plugin is at [3].
>>> >>> > I'm using official apache maven-2.2.1 build.
>>> >>> >
>>> >>> > Your help is much appreciated.
>>> >>> >
>>> >>> > [1]
>>> >>>
>>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>>> >>> > [2] http://pastebin.com/yprQU2D2
>>> >>> > [3] http://pastebin.com/Y375dwMg
>>> >>> >
>>> >>> > Thanks,
>>> >>> > --Kasun
>>> >>> >
>>> >>> > --
>>> >>> > ~~~*******'''''''''''''*******~~~
>>> >>> > Kasun Gajasinghe,
>>> >>> > University of Moratuwa,
>>> >>> > Sri Lanka.
>>> >>> > Blog: http://blog.kasunbg.org
>>> >>> > Twitter: http://twitter.com/kasunbg
>>> >>> >
>>> >>> > ---------------------------------------------------------------------
>>> >>> > To unsubscribe, e-mail: [hidden email]
>>> >>> > For additional commands, e-mail: [hidden email]
>>> >>> >
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: [hidden email]
>>> >>> For additional commands, e-mail: [hidden email]
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> ~~~*******'''''''''''''*******~~~
>>> Kasun Gajasinghe,
>>> University of Moratuwa,
>>> Sri Lanka.
>>> Blog: http://blog.kasunbg.org
>>> Twitter: http://twitter.com/kasunbg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
>
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Damian Bradicich]

I'm still not seeing the problem, certainly a specific release of a parent
pom would be static, but if you need to update versions, you update the pom
and release a new version, then update your projects to use it as necessary.
 It is a simple workflow, and leaves a single place where all versions are
defined, and will give you the least amount of trouble as you are not trying
to hack up some local repo metadata to achieve the exact same thing.

I mean this is the _exact_ kind of thing maven excels at.  You will forever
have the release of the parent pom, and will always be able to build older
releases of your projects (as i see benson has already mentioned in his
latest reply), anyone with simple pom knowledge can update the parent pom to
use a new version of plugin A/B/C.

But I (like maven) can't force you into anything, just guide you to the best
solution  ;-)

Damian

On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe <[hidden email]> wrote:

> On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
> <[hidden email]> wrote:
> > But why ?  simply have a top level parent pom that is solely for defining
> > your plugin versions (and anything else that may cover all of your
> > projects), you don't need any project specific logic in there.  The
> parent
> > doesn't need to list any of the children that use it (and act as an
> > aggregator), that is just a common use of a parent.
>
> This would not work because the parent-pom file you are saying will be
> static. By static I meant that the parent pom file can not be modified
> later on after it goes in to the m2 repo. So, when a need arise to add
> a new plugin version, how it can be done?
> The way to do this is by maintaining maven-metadata.xml files which
> exists one per plugin under m2 repo (for example, for
> maven-compiler-plugin, it's in
>
> ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml).
> This way, I don't have a problem when a new plugin is added to the
> repo, right?
>
> It doesn't really matter whether this can be done via
> maven-metadata.xml or by some other means. We just need to make the
> setting details file per-plugin.
>
> --Kasun
>
> >
> > Damian
> >
> > On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]
> >wrote:
> >
> >> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
> >> <[hidden email]> wrote:
> >> > err...pluginManagement section even ;)
> >> >
> >> > Damian
> >> >
> >> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
> >> > <[hidden email]>wrote:
> >> >
> >> >> Why not define the pluginDependency section in a parent pom, then
> each
> >> of
> >> >> your projects uses this as a parent, and pulls in all the plugin dep
> >> >> versions defined in it (or overrides in project pom if necessary).
> >>  Seems
> >> >> that would be simplest solution
> >>
> >> Since these projects are unrelated, they can't be glued together via a
> >> parent pom.
> >>
> >> Thanks,
> >> --Kasun
> >>
> >> >>
> >> >> Damian
> >> >>
> >> >>
> >> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
> >> [hidden email]>wrote:
> >> >>
> >> >>> I don't know about plugin-registry.xml, but you can distribute a
> >> >>> settings.xml for use with -gs that has an active-by-default profile
> >> >>> with a pluginManagement section that does the job.
> >> >>>
> >> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <
> [hidden email]>
> >> >>> wrote:
> >> >>> > Hi,
> >> >>> > I have a requirement where I need to specify specific versions for
> a
> >> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
> >> option
> >> >>> > because we need to set the plugin versions for a vast number of
> >> >>> > _unrelated_ builds.
> >> >>> > As I've found at [1], I've manually created a plugin-registry.xml
> >> file
> >> >>> > with needed plugin versions added. In addition to that, I've
> created
> >> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
> >> >>> > directories, pointing to <latest> and <release> versions.
> >> >>> >
> >> >>> > But, unfortunately, these specified versions were not picked up by
> >> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
> >> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat
> outdated
> >> >>> > because --check-plugin-latest parameter doesn't available anymore.
> >> So,
> >> >>> > I'm asking, does the plugin-registry.xml is still used by maven?
> If
> >> >>> > not what is the mechanism for specifying specific plugin versions
> >> >>> > (apart from current/parent pom)?
> >> >>> >
> >> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
> >> >>> > anymore, but debug mode shows that mvn retrieves data from that
> file.
> >> >>> > ) Apparently, maven-metada-local.xml isn't created automatically
> for
> >> >>> > me either. How I can instruct mvn to do that?
> >> >>> >
> >> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for
> that.
> >> >>> > So, hope the format is correct!). maven-metadata-local.xml of
> >> >>> > maven-compiler-plugin is at [3].
> >> >>> > I'm using official apache maven-2.2.1 build.
> >> >>> >
> >> >>> > Your help is much appreciated.
> >> >>> >
> >> >>> > [1]
> >> >>>
> >>
> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
> >> >>> > [2] http://pastebin.com/yprQU2D2
> >> >>> > [3] http://pastebin.com/Y375dwMg
> >> >>> >
> >> >>> > Thanks,
> >> >>> > --Kasun
> >> >>> >
> >> >>> > --
> >> >>> > ~~~*******'''''''''''''*******~~~
> >> >>> > Kasun Gajasinghe,
> >> >>> > University of Moratuwa,
> >> >>> > Sri Lanka.
> >> >>> > Blog: http://blog.kasunbg.org
> >> >>> > Twitter: http://twitter.com/kasunbg
> >> >>> >
> >> >>> >
> ---------------------------------------------------------------------
> >> >>> > To unsubscribe, e-mail: [hidden email]
> >> >>> > For additional commands, e-mail: [hidden email]
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: [hidden email]
> >> >>> For additional commands, e-mail: [hidden email]
> >> >>>
> >> >>>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> ~~~*******'''''''''''''*******~~~
> >> Kasun Gajasinghe,
> >> University of Moratuwa,
> >> Sri Lanka.
> >> Blog: http://blog.kasunbg.org
> >> Twitter: http://twitter.com/kasunbg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
>
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Kasun Gajasinghe]

On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies <[hidden email]> wrote:
> As a general principle, the design of maven is trending toward locking
> down the versions of plugins for a build. Otherwise, you can't grab an
> old version of the source from a tag and depend on building it.
>
> Therefore, the idea of a separate 'control panel' for plugin versions
> is not popular. Global settings.xml is about the best you are going to
> do. Some day, conceivably, even that might stop working, but don't
> lose sleep over it.

Yeah? Well I'm not sure about the reasons for the decision of maven
devs, but I can tell this. Currently, all poms extend maven Super Pom
[1] which contains some set of plugins at the release of maven. Most
of the plugins are much older (some from 2007/08) in the super pom.
for example, maven-compiler-plugin version is 2.0.2 in the super pom,
which is from 2007. So, doesn't having an intermediary layer that will
point to newer set of plugins is justified? At least It's ok if maven
just picked the latest plugin version installed in the m2 repo which
might be set via a setting.

Anyway, I just needed to know the current implementation details. To
give my two cents, I think the docs need an update especially since
maven came to 3.0 era. (Yes, I understand the time constraints. Just
expressing my thoughts.)

[1] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Super_POM

Thanks,
--Kasun

>
> On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe <[hidden email]> wrote:
>> On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
>> <[hidden email]> wrote:
>>> But why ?  simply have a top level parent pom that is solely for defining
>>> your plugin versions (and anything else that may cover all of your
>>> projects), you don't need any project specific logic in there.  The parent
>>> doesn't need to list any of the children that use it (and act as an
>>> aggregator), that is just a common use of a parent.
>>
>> This would not work because the parent-pom file you are saying will be
>> static. By static I meant that the parent pom file can not be modified
>> later on after it goes in to the m2 repo. So, when a need arise to add
>> a new plugin version, how it can be done?
>> The way to do this is by maintaining maven-metadata.xml files which
>> exists one per plugin under m2 repo (for example, for
>> maven-compiler-plugin, it's in
>> ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml).
>> This way, I don't have a problem when a new plugin is added to the
>> repo, right?
>>
>> It doesn't really matter whether this can be done via
>> maven-metadata.xml or by some other means. We just need to make the
>> setting details file per-plugin.
>>
>> --Kasun
>>
>>>
>>> Damian
>>>
>>> On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]>wrote:
>>>
>>>> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
>>>> <[hidden email]> wrote:
>>>> > err...pluginManagement section even ;)
>>>> >
>>>> > Damian
>>>> >
>>>> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
>>>> > <[hidden email]>wrote:
>>>> >
>>>> >> Why not define the pluginDependency section in a parent pom, then each
>>>> of
>>>> >> your projects uses this as a parent, and pulls in all the plugin dep
>>>> >> versions defined in it (or overrides in project pom if necessary).
>>>>  Seems
>>>> >> that would be simplest solution
>>>>
>>>> Since these projects are unrelated, they can't be glued together via a
>>>> parent pom.
>>>>
>>>> Thanks,
>>>> --Kasun
>>>>
>>>> >>
>>>> >> Damian
>>>> >>
>>>> >>
>>>> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
>>>> [hidden email]>wrote:
>>>> >>
>>>> >>> I don't know about plugin-registry.xml, but you can distribute a
>>>> >>> settings.xml for use with -gs that has an active-by-default profile
>>>> >>> with a pluginManagement section that does the job.
>>>> >>>
>>>> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]>
>>>> >>> wrote:
>>>> >>> > Hi,
>>>> >>> > I have a requirement where I need to specify specific versions for a
>>>> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
>>>> option
>>>> >>> > because we need to set the plugin versions for a vast number of
>>>> >>> > _unrelated_ builds.
>>>> >>> > As I've found at [1], I've manually created a plugin-registry.xml
>>>> file
>>>> >>> > with needed plugin versions added. In addition to that, I've created
>>>> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
>>>> >>> > directories, pointing to <latest> and <release> versions.
>>>> >>> >
>>>> >>> > But, unfortunately, these specified versions were not picked up by
>>>> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>>>> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>>>> >>> > because --check-plugin-latest parameter doesn't available anymore.
>>>> So,
>>>> >>> > I'm asking, does the plugin-registry.xml is still used by maven? If
>>>> >>> > not what is the mechanism for specifying specific plugin versions
>>>> >>> > (apart from current/parent pom)?
>>>> >>> >
>>>> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
>>>> >>> > anymore, but debug mode shows that mvn retrieves data from that file.
>>>> >>> > ) Apparently, maven-metada-local.xml isn't created automatically for
>>>> >>> > me either. How I can instruct mvn to do that?
>>>> >>> >
>>>> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for that.
>>>> >>> > So, hope the format is correct!). maven-metadata-local.xml of
>>>> >>> > maven-compiler-plugin is at [3].
>>>> >>> > I'm using official apache maven-2.2.1 build.
>>>> >>> >
>>>> >>> > Your help is much appreciated.
>>>> >>> >
>>>> >>> > [1]
>>>> >>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>>>> >>> > [2] http://pastebin.com/yprQU2D2
>>>> >>> > [3] http://pastebin.com/Y375dwMg
>>>> >>> >
>>>> >>> > Thanks,
>>>> >>> > --Kasun
>>>> >>> >
>>>> >>> > --
>>>> >>> > ~~~*******'''''''''''''*******~~~
>>>> >>> > Kasun Gajasinghe,
>>>> >>> > University of Moratuwa,
>>>> >>> > Sri Lanka.
>>>> >>> > Blog: http://blog.kasunbg.org
>>>> >>> > Twitter: http://twitter.com/kasunbg
>>>> >>> >
>>>> >>> > ---------------------------------------------------------------------
>>>> >>> > To unsubscribe, e-mail: [hidden email]
>>>> >>> > For additional commands, e-mail: [hidden email]
>>>> >>> >
>>>> >>> >
>>>> >>>
>>>> >>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: [hidden email]
>>>> >>> For additional commands, e-mail: [hidden email]
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> ~~~*******'''''''''''''*******~~~
>>>> Kasun Gajasinghe,
>>>> University of Moratuwa,
>>>> Sri Lanka.
>>>> Blog: http://blog.kasunbg.org
>>>> Twitter: http://twitter.com/kasunbg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> ~~~*******'''''''''''''*******~~~
>> Kasun Gajasinghe,
>> University of Moratuwa,
>> Sri Lanka.
>> Blog: http://blog.kasunbg.org
>> Twitter: http://twitter.com/kasunbg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kasun Gajasinghe]

On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich
<[hidden email]> wrote:

> I'm still not seeing the problem, certainly a specific release of a parent
> pom would be static, but if you need to update versions, you update the pom
> and release a new version, then update your projects to use it as necessary.
>  It is a simple workflow, and leaves a single place where all versions are
> defined, and will give you the least amount of trouble as you are not trying
> to hack up some local repo metadata to achieve the exact same thing.
>
> I mean this is the _exact_ kind of thing maven excels at.  You will forever
> have the release of the parent pom, and will always be able to build older
> releases of your projects (as i see benson has already mentioned in his
> latest reply), anyone with simple pom knowledge can update the parent pom to
> use a new version of plugin A/B/C.
>

As I said, this is a solution, but in our case, unfortunately, only
partial. You may have not aware that I'm working on building packages
to be installed at system level in Gentoo Linux. The overhead that
adds for a new parent pom like this is pretty high. I'll just say that
there are complications (such as build-order, which package owns the
pom, maven re-installations etc.) when it comes to packaging at
operating system level.

I have more than enough pom knowledge to update the pom if needed. But
our pom handling and maven invocation is automated. Manually, editing
the pom with the available plugin versions is much complicated, and
may not be possible with the limitations imposed by the system.

Anyway, I'm evaluating this solution deeply as well. I'm just looking
for the optimal, and elegant solution that maven already has as I
figured. In the given solutions, I like this most because this gives
the needed control to some extent.

> But I (like maven) can't force you into anything, just guide you to the best
> solution  ;-)

I know, and I respect that. :)

Thanks,
--Kasun

>
> Damian
>
> On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe <[hidden email]> wrote:
>
>> On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
>> <[hidden email]> wrote:
>> > But why ?  simply have a top level parent pom that is solely for defining
>> > your plugin versions (and anything else that may cover all of your
>> > projects), you don't need any project specific logic in there.  The
>> parent
>> > doesn't need to list any of the children that use it (and act as an
>> > aggregator), that is just a common use of a parent.
>>
>> This would not work because the parent-pom file you are saying will be
>> static. By static I meant that the parent pom file can not be modified
>> later on after it goes in to the m2 repo. So, when a need arise to add
>> a new plugin version, how it can be done?
>> The way to do this is by maintaining maven-metadata.xml files which
>> exists one per plugin under m2 repo (for example, for
>> maven-compiler-plugin, it's in
>>
>> ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml).
>> This way, I don't have a problem when a new plugin is added to the
>> repo, right?
>>
>> It doesn't really matter whether this can be done via
>> maven-metadata.xml or by some other means. We just need to make the
>> setting details file per-plugin.
>>
>> --Kasun
>>
>> >
>> > Damian
>> >
>> > On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <[hidden email]
>> >wrote:
>> >
>> >> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
>> >> <[hidden email]> wrote:
>> >> > err...pluginManagement section even ;)
>> >> >
>> >> > Damian
>> >> >
>> >> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
>> >> > <[hidden email]>wrote:
>> >> >
>> >> >> Why not define the pluginDependency section in a parent pom, then
>> each
>> >> of
>> >> >> your projects uses this as a parent, and pulls in all the plugin dep
>> >> >> versions defined in it (or overrides in project pom if necessary).
>> >>  Seems
>> >> >> that would be simplest solution
>> >>
>> >> Since these projects are unrelated, they can't be glued together via a
>> >> parent pom.
>> >>
>> >> Thanks,
>> >> --Kasun
>> >>
>> >> >>
>> >> >> Damian
>> >> >>
>> >> >>
>> >> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies <
>> >> [hidden email]>wrote:
>> >> >>
>> >> >>> I don't know about plugin-registry.xml, but you can distribute a
>> >> >>> settings.xml for use with -gs that has an active-by-default profile
>> >> >>> with a pluginManagement section that does the job.
>> >> >>>
>> >> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <
>> [hidden email]>
>> >> >>> wrote:
>> >> >>> > Hi,
>> >> >>> > I have a requirement where I need to specify specific versions for
>> a
>> >> >>> > set of (basic) plugins. Adding the versions to the pom isn't an
>> >> option
>> >> >>> > because we need to set the plugin versions for a vast number of
>> >> >>> > _unrelated_ builds.
>> >> >>> > As I've found at [1], I've manually created a plugin-registry.xml
>> >> file
>> >> >>> > with needed plugin versions added. In addition to that, I've
>> created
>> >> >>> > maven-metadata-local.xml file in the m2 repo under the plugin
>> >> >>> > directories, pointing to <latest> and <release> versions.
>> >> >>> >
>> >> >>> > But, unfortunately, these specified versions were not picked up by
>> >> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>> >> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat
>> outdated
>> >> >>> > because --check-plugin-latest parameter doesn't available anymore.
>> >> So,
>> >> >>> > I'm asking, does the plugin-registry.xml is still used by maven?
>> If
>> >> >>> > not what is the mechanism for specifying specific plugin versions
>> >> >>> > (apart from current/parent pom)?
>> >> >>> >
>> >> >>> > (I've seen in some posts that the plugin-registry.xml isn't used
>> >> >>> > anymore, but debug mode shows that mvn retrieves data from that
>> file.
>> >> >>> > ) Apparently, maven-metada-local.xml isn't created automatically
>> for
>> >> >>> > me either. How I can instruct mvn to do that?
>> >> >>> >
>> >> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for
>> that.
>> >> >>> > So, hope the format is correct!). maven-metadata-local.xml of
>> >> >>> > maven-compiler-plugin is at [3].
>> >> >>> > I'm using official apache maven-2.2.1 build.
>> >> >>> >
>> >> >>> > Your help is much appreciated.
>> >> >>> >
>> >> >>> > [1]
>> >> >>>
>> >>
>> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>> >> >>> > [2] http://pastebin.com/yprQU2D2
>> >> >>> > [3] http://pastebin.com/Y375dwMg
>> >> >>> >
>> >> >>> > Thanks,
>> >> >>> > --Kasun
>> >> >>> >
>> >> >>> > --
>> >> >>> > ~~~*******'''''''''''''*******~~~
>> >> >>> > Kasun Gajasinghe,
>> >> >>> > University of Moratuwa,
>> >> >>> > Sri Lanka.
>> >> >>> > Blog: http://blog.kasunbg.org
>> >> >>> > Twitter: http://twitter.com/kasunbg
>> >> >>> >
>> >> >>> >
>> ---------------------------------------------------------------------
>> >> >>> > To unsubscribe, e-mail: [hidden email]
>> >> >>> > For additional commands, e-mail: [hidden email]
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: [hidden email]
>> >> >>> For additional commands, e-mail: [hidden email]
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> ~~~*******'''''''''''''*******~~~
>> >> Kasun Gajasinghe,
>> >> University of Moratuwa,
>> >> Sri Lanka.
>> >> Blog: http://blog.kasunbg.org
>> >> Twitter: http://twitter.com/kasunbg
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> ~~~*******'''''''''''''*******~~~
>> Kasun Gajasinghe,
>> University of Moratuwa,
>> Sri Lanka.
>> Blog: http://blog.kasunbg.org
>> Twitter: http://twitter.com/kasunbg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Ansgar Konermann]

Am 26.07.2011 01:27, schrieb Kasun Gajasinghe:
> Manually, editing
> the pom with the available plugin versions is much complicated,
http://mojo.codehaus.org/versions-maven-plugin/update-parent-mojo.html

Automate this using a CI server and you're probably mostly done.

Best

Ansgar

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Ansgar Konermann]

Am 26.07.2011 00:56, schrieb Kasun Gajasinghe:
> So, doesn't having an intermediary layer that will
> point to newer set of plugins is justified?
Sure.

Simplest solution that will work: use your own parent pom with an
updated <pluginManagement> section.

Ansgar

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Ansgar Konermann]

Am 26.07.2011 21:14, schrieb Ansgar Konermann:
> Am 26.07.2011 01:27, schrieb Kasun Gajasinghe:
I'm sorry, wrong list.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Gier]

settings.xml can include pluginManagement in a profile?  I thought you
could only include a few things like repos and properties, at least
that's what the docs say.

http://maven.apache.org/ref/3.0.3/maven-settings/settings.html

On 07/25/2011 06:43 AM, Benson Margulies wrote:

> I don't know about plugin-registry.xml, but you can distribute a
> settings.xml for use with -gs that has an active-by-default profile
> with a pluginManagement section that does the job.
>
> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe <[hidden email]> wrote:
>> Hi,
>> I have a requirement where I need to specify specific versions for a
>> set of (basic) plugins. Adding the versions to the pom isn't an option
>> because we need to set the plugin versions for a vast number of
>> _unrelated_ builds.
>> As I've found at [1], I've manually created a plugin-registry.xml file
>> with needed plugin versions added. In addition to that, I've created
>> maven-metadata-local.xml file in the m2 repo under the plugin
>> directories, pointing to <latest> and <release> versions.
>>
>> But, unfortunately, these specified versions were not picked up by
>> mvn. I needed latest maven-compiler-plugin version 2.3.2, but it
>> always try to use 2.0.2. I've noticed that [1] is somewhat outdated
>> because --check-plugin-latest parameter doesn't available anymore. So,
>> I'm asking, does the plugin-registry.xml is still used by maven? If
>> not what is the mechanism for specifying specific plugin versions
>> (apart from current/parent pom)?
>>
>> (I've seen in some posts that the plugin-registry.xml isn't used
>> anymore, but debug mode shows that mvn retrieves data from that file.
>> ) Apparently, maven-metada-local.xml isn't created automatically for
>> me either. How I can instruct mvn to do that?
>>
>> My plugin-registry.xml is at [2]. (There wasn't a template for that.
>> So, hope the format is correct!). maven-metadata-local.xml of
>> maven-compiler-plugin is at [3].
>> I'm using official apache maven-2.2.1 build.
>>
>> Your help is much appreciated.
>>
>> [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html
>> [2] http://pastebin.com/yprQU2D2
>> [3] http://pastebin.com/Y375dwMg
>>
>> Thanks,
>> --Kasun
>>
>> --
>> ~~~*******'''''''''''''*******~~~
>> Kasun Gajasinghe,
>> University of Moratuwa,
>> Sri Lanka.
>> Blog: http://blog.kasunbg.org
>> Twitter: http://twitter.com/kasunbg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kasun Gajasinghe]

On 27 Jul 2011, at 01:27, Ansgar Konermann <[hidden email]
 > wrote:

> Am 26.07.2011 00:56, schrieb Kasun Gajasinghe:
>> So, doesn't having an intermediary layer that will
>> point to newer set of plugins is justified?
> Sure.
>
> Simplest solution that will work: use your own parent pom with an
> updated <pluginManagement> section.

As I explained before, parent pom thing has few caveats.
Btw, lot of problems occured to me because of the maven super pom,  
which, apparently has some hard-coded (quite old) plugin versions. (As  
I've read [1], the super pom is something like Java's java.lang.Object  
that every class inherits properties from.)

So, I could get over some issues if I can patch the plugin versions in  
super pom according to our needs. Unfortunately, I can't find it  
exists in source.
Can anyone shed a light on where I could find the super pom?

Thanks,
Kasun

[1] http://maven.apache.org/pom.html#The_Super_POM

>
> Ansgar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kasun Gajasinghe]

On Wed, Jul 27, 2011 at 10:05 PM, Ansgar Konermann
<[hidden email]> wrote:
> Am 27.07.2011 08:16, schrieb Kasun Gajasinghe:
>> We don't allow downloading of different versions of same plugin which
>> in most cases does the 'same' job! So, we need the ability to set a
>> default plugin versions that are available on the gentoo system.
> Hi Kasun,
>
> what about this: configure a local <pluginRepository> in Maven's global
> settings.xml [1] file. Pre-load it with all the plugins and plugin
> dependencies your maven installation will be allowed to use.

Ansgar,
well, this is possible, I'm working on some subtle gentoo-specific
things I need to do first to test this out. Anyway, I already know
this, and have specified about this in my original post. I'm looking
for this and something beyond that. That is, set <checkLatest> true
and retrieve plugins version from there.
[2] says,
checkLatest - Specifies whether the LATEST artifact metadata should be
consulted while determining versions for unregistered plugins.

I'm looking for that. I figured that it needs to set via
maven-metadata.xml files. I'm not exactly sure that maven-metadata.xml
is the file to be used for this purpose though.

[2] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html

>
> Best
>
> Ansgar
>
> [1] http://maven.apache.org/settings.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Larry Shatzer, Jr.]

On Mon, Jul 25, 2011 at 9:30 AM, Kasun Gajasinghe <[hidden email]> wrote:

> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
> <[hidden email]> wrote:
>> err...pluginManagement section even ;)
>>
>> Damian
>>
>> On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
>> <[hidden email]>wrote:
>>
>>> Why not define the pluginDependency section in a parent pom, then each of
>>> your projects uses this as a parent, and pulls in all the plugin dep
>>> versions defined in it (or overrides in project pom if necessary).  Seems
>>> that would be simplest solution
>
> Since these projects are unrelated, they can't be glued together via a
> parent pom.

I don't see why not. Consider the following example:
http://img.skitch.com/20110727-b3j3j8fk2rg4s2h9exm225skyd.png You just
need to have a hierarchy of parent poms.

Sure, if you update the top Corporate Super-Pom, you will then need to
update the other parent poms that depend on that pom, but this way you
can share only the most common stuff, such as plugin versions and
generic configurations in the corporate super pom, and then in each of
the other parent poms, you get more specific.

-- Larry

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]