commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [all] Changing maven groupIDs [WAS: [IO] Next version of IO - should this be 2.0?]
Date Sun, 07 Mar 2010 21:03:09 GMT
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 <> wrote:
>>>> On 2010-03-07 12:41, Niall Pemberton wrote:
>>>>> On Sat, Mar 6, 2010 at 12:15 AM, sebb <> wrote:
>>>>>> The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that
>>>>>> next release should be 2.0 rather 1.5, as IO now requires Java 1.5,
>>>>>> that requires a major version change.
>>>>> The plan was to release it as 2.0 - but IMO its not a requirement.
>>>>>> Does that make sense?
>>>>>> If so, then the maven id can also be fixed (see IO-125).
>>>>> -1 - see comments on JIRA ticket
>>>> 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@


>>>> 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.
> Niall
>>> Niall
>>>>> Niall
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message