commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: commons-parent-7 discussion
Date Sat, 12 Jan 2008 00:20:41 GMT
On Jan 11, 2008 11:29 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> Jochen Wiedmann wrote:
> > On Jan 11, 2008 10:57 AM, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> >
> >> Theres also the issue of specifying the "version" of the
> >> remote-resources-plugin - which in previous discussions people
> >> objected to. Please Note this is not configuring commons-parent to
> >> *use* that plugin - but just to specify the version number *if* a
> >> component does use it. I don't mind it going in and it has no impact
> >> unless components use it. Does anyone still have a problem with doing
> >> this? Also are there any other changes people think should be made
> >> before trying to release commons-parent-7?
> >
> > I have no particular problem with it, apart from the fact that I find
> > it pointless.
> >
> > If there is some code that actually uses the plugin, then that makes
> > sense. This code might be contained in some profile, in other words,
> > not used unless explicitly requested. But just to fix a version
> > number? What for?
>
> The reason is to have reproducible builds. It makes sure that, no matter
> who is building component A, the end result will always be the same.

This is not quite the case - reproducability is the reason for
specifying the version, but not the reason for specifying the version
in the parent pom. The reason for specifying version numbers in the
parent is to not have to go through endless component poms updating
version numbers - maintain the version numbers in the parent and just
keep the commons-parent version up-to-date in the components.

Niall

> Specifying versions for all plugins is considered a best practice. This
> has been discussed a lot on the Maven mailing-lists. I can give you some
>   pointers if you like.
>
> > Jochen
> >

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


Mime
View raw message