commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: [pool] time to move groupId?
Date Sat, 16 Oct 2010 16:23:02 GMT
On Sat, Oct 16, 2010 at 4:02 PM, James Carman
<> wrote:
> On Sat, Oct 16, 2010 at 10:34 AM, Niall Pemberton
> <> wrote:
>> +1 to what Dennis says. Changing the artifactId doesn't accompilsh
>> anything additional if the groupId is changing.
> Other than keeping things consistent.  But, apparently folks around
> here aren't as concerned with that as I am, because we have this
> argument every time we bring this stuff up.  I keep saying "consistent
> consistent" and other folks just say "it's up to the project to do
> whatever they want" or "why do we have to do that" or "we can just
> change the group id" or whatever.

Consistency is good, but deciding something based purely on
*consistency* rather than the merits of the situation is mindless. On
top of that sometimes its not possible to get unified agreement by a
large diverse group of developers. We are a federation of components
here in Commons which is unlike most ASF projects - in other projects
its necessary to decide single approaches because people are working
on the same code base. Here the code bases and developers are often
unrelated and its divisive for people to start dictating to a
component they don't work on. IMO one of the main ASF principles is
the people who do the work make the decisions. Commons wide *rules*
should be kept to a minimum. We should promote consistency, but at the
same time not get hung up on it.

> Apache Commons should try to do things in a consistent fashion.  If
> not, then why don't we just promote all subprojects to TLPs and be
> done with it.  There's no reason for them to be under one umbrella.

The vast majority of these components would never work as a TLP
because they don't individually have enough developers. Commons is a
community of people interested in developing small components and
prepared to help each other out to provide the necessary oversight so
that collectively we can function here at the ASF. Its important to
tolerate the differences between components rather than trying to
impose a *one-rule-to-rule-them-all* type approach.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message