commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [all] Changing maven groupIDs [WAS: [IO] Next version of IO - should this be 2.0?]
Date Tue, 09 Mar 2010 03:27:28 GMT
On Sun, Mar 7, 2010 at 4:03 PM, Phil Steitz <> wrote:
> Niall Pemberton wrote:
>> On Sun, Mar 7, 2010 at 5:28 PM, Dennis Lundberg <> wrote:
>>> On 2010-03-07 16:45, Niall Pemberton wrote:
>>>> On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg <>
>>>>> We need to make this switch sooner rather than later. Currently every
>>>>> release with a groupId och commons-* requires manual work from the
>>>>> people who manage Maven central repository. We're just about the only
>>>>> Apache project left not using a groupId of org.apache.*.
>>>> I thought it was only when we did the first m2 release for a component
>>>> and not for subsequent m2 releases for the group. Is that not the
>>>> case?
>>> It used to be that way, but it has changed. The repo maintainers want to
>>> remove all manual stuff, including anything from Apache that is not
>>> under groupId org.apache.*. We (the ASF) don't want anything pushed to
>>> the central repository that is from under groupId other than org.apache.*.
>>> It is only a matter of time before our current way (groupid commons-*)
>>> will be shut down completely. If people have opinions about this I
>>> suggest that you take them to repository@a.o for discussion.
>> OK
> I think we need to have that discussion. We (Commons) are happy to
> contribute to and subsequently follow ASF policy on how we publish
> maven artifacts. Unless I missed it on repository@, though, we have
> not as ASF agreed on a policy to retire the "legacy" groupIds. We
> also seem to be lacking consensus / clarity on how exactly we can
> accomplish "relocation" without potentially serious implications for
> the users of heavily-depended-on components.
> Therefore here in commons, I think we have agreed that we will move
> to org.apache.commons groupId when we make incompatible changes in a
> new release.  That *must* coincide with a major release and it *may*
> coincide with a change in package name.  It is possible, as in the
> present case with [io], that a major release will not introduce
> incompatible API changes, in which case we will not change the
> groupId. I see us cutting patch releases using "legacy" IDs for some
> time to come.
> Please commons ppl respond if you disagree with the statements
> above.  Assuming we are in agreement, we can continue the discussion
> on repository@

I think thats a good summary.

> Phil
>>>>> We have previously said that we should make the switch to a groupId of
>>>>> org.apache.commons when we do a major release. IMO we need to stick by
>>>>> that decision.
>>>> I don't remember that decision, do you have a link to the thread? Even
>>>> if we did - this is going to cause problems for users who change their
>>>> dependency to the latest - but also depend on other artifacts that
>>>> have an older dependency on commons-io. Is this user pain worth it?
>>> I found this thread, which touches the issue:
>>> For such a change to be totally transparent we cannot rely on the
>>> relocation feature of Maven, which has been discussed before. We would
>>> have to change the package name, which I think was done in lang, from
>>> to org.apache.commons.io2.
>> I'm sorry but having the build-tool/repository force a package rename is nuts.

Indeed it is.


>> Niall

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

View raw message