[parent-pom] versions

[Torsten Curdt <tc...@apache.org>]

I've noticed that the plugin versions are not specified in the  
commons parent pom. From my experience this is a *really* bad idea as  
maven then picks the most recent from local repository. Which again  
can easily lead to inconsistent site builds across the team. So if no  
one objects I will add the latest version information to the plugins.  
For a reproducible site build.

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Dennis Lundberg <de...@apache.org>]

Henri Yandell wrote:
> On 4/2/07, Torsten Curdt <tc...@apache.org> wrote:
>>
>> On 02.04.2007, at 09:49, Stephen Colebourne wrote:
>>
>> > Henri Yandell wrote:
>> >> Personally I think we should only have the plugins defined if the
>> >> release jar itself needs them for stability.
>>
>> ...and then have the project define the reports they want?
> 
> Sorry - plugin versions.
> 
> Or is that the problem now, you can't use a version that's tied to
> your Maven installation because said plugin is not a part of the core
> system?

Speaking of Maven 2 here. The Maven installation doesn't contain any 
plugins, they are downloaded when they are needed. Unless you specify 
the version of a plugin that you want to use, you get the "latest" 
version. This in turn is found in the metadata in the repository, from 
which the plugin is downloaded.

>>
>> >> Otherwise we just deal
>> >> with whatever pain Maven is throwing everyone's way and yell at them
>> >> to fix.
>> >
>> > Er why? It is not our job to be gump and test commons builds
>> > against the latest random collection of maven plugins.
>>
>> Don't get that either. I want to make our life's less painful.
>> Specifying the versions helps a great deal with that.
> 
> Maybe I'm being Maven1 minded.
> 
> I don't think we should be wasting time figuring out which plugin
> version is good and which is bad for the many many plugins that are
> just there to stick crap on the site.
> 
> Then again - it's in the central pom and not each project so not a
> biggy I guess. Go for it.
> 
> Hen


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Henri Yandell <fl...@gmail.com>]

On 4/2/07, Torsten Curdt <tc...@apache.org> wrote:
>
> On 02.04.2007, at 09:49, Stephen Colebourne wrote:
>
> > Henri Yandell wrote:
> >> Personally I think we should only have the plugins defined if the
> >> release jar itself needs them for stability.
>
> ...and then have the project define the reports they want?

Sorry - plugin versions.

Or is that the problem now, you can't use a version that's tied to
your Maven installation because said plugin is not a part of the core
system?

>
> >> Otherwise we just deal
> >> with whatever pain Maven is throwing everyone's way and yell at them
> >> to fix.
> >
> > Er why? It is not our job to be gump and test commons builds
> > against the latest random collection of maven plugins.
>
> Don't get that either. I want to make our life's less painful.
> Specifying the versions helps a great deal with that.

Maybe I'm being Maven1 minded.

I don't think we should be wasting time figuring out which plugin
version is good and which is bad for the many many plugins that are
just there to stick crap on the site.

Then again - it's in the central pom and not each project so not a
biggy I guess. Go for it.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Torsten Curdt <tc...@apache.org>]

On 02.04.2007, at 09:49, Stephen Colebourne wrote:

> Henri Yandell wrote:
>> Personally I think we should only have the plugins defined if the
>> release jar itself needs them for stability.

...and then have the project define the reports they want?

>> Otherwise we just deal
>> with whatever pain Maven is throwing everyone's way and yell at them
>> to fix.
>
> Er why? It is not our job to be gump and test commons builds  
> against the latest random collection of maven plugins.

Don't get that either. I want to make our life's less painful.  
Specifying the versions helps a great deal with that.

> If anyone looks objectively at the amount of time spent on maven on  
> this mailing list over the past few years its incredible. I'd  
> suggest its been a big distraction from actually coding for some  
> people.

True

> The basic problem in this case is that maven builds aren't  
> repeatable. They are only repeatable if you have exactly the same  
> version of maven and each one of its many plugins.

The good thing - you *can* achieve this. The bad thing - it's not the  
default.

> This isn't something that plagues ant - there if you write a build  
> script it keeps on working - its called backwards compatibility.

I have been bashing maven once I did the multi-project move for  
JCI ...but I am now more exposed to ant again and I have to say for  
small builds ant may be OK ...but for big builds it makes you cry. So  
I am again back to preferring maven over ant ...but we'll see how the  
JCI release will work out :)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Stephen Colebourne <sc...@btopenworld.com>]

Henri Yandell wrote:
> Personally I think we should only have the plugins defined if the
> release jar itself needs them for stability. Otherwise we just deal
> with whatever pain Maven is throwing everyone's way and yell at them
> to fix.

Er why? It is not our job to be gump and test commons builds against the 
latest random collection of maven plugins.

<rant>
If anyone looks objectively at the amount of time spent on maven on this 
mailing list over the past few years its incredible. I'd suggest its 
been a big distraction from actually coding for some people.

The basic problem in this case is that maven builds aren't repeatable. 
They are only repeatable if you have exactly the same version of maven 
and each one of its many plugins.

This isn't something that plagues ant - there if you write a build 
script it keeps on working - its called backwards compatibility.
</rant>

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Henri Yandell <fl...@gmail.com>]

On 4/1/07, Torsten Curdt <tc...@apache.org> wrote:
> I've noticed that the plugin versions are not specified in the
> commons parent pom. From my experience this is a *really* bad idea as
> maven then picks the most recent from local repository. Which again
> can easily lead to inconsistent site builds across the team. So if no
> one objects I will add the latest version information to the plugins.
> For a reproducible site build.

Personally I think we should only have the plugins defined if the
release jar itself needs them for stability. Otherwise we just deal
with whatever pain Maven is throwing everyone's way and yell at them
to fix.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [parent-pom] versions

[Dennis Lundberg <de...@apache.org>]

Torsten Curdt wrote:
> I've noticed that the plugin versions are not specified in the commons 
> parent pom. From my experience this is a *really* bad idea as maven then 
> picks the most recent from local repository. Which again can easily lead 
> to inconsistent site builds across the team. So if no one objects I will 
> add the latest version information to the plugins. For a reproducible 
> site build.
> 
> cheers
> -- 
> Torsten

+1

This is a good idea, and also a recommended practice.

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org