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: [all] Changing maven groupIDs [WAS: [IO] Next version of IO - should this be 2.0?]
Date Sun, 07 Mar 2010 23:16:15 GMT
On Sun, Mar 7, 2010 at 9:53 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> Phil Steitz a écrit :
>> Niall Pemberton wrote:
>>> On Sun, Mar 7, 2010 at 5:28 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>>>> On 2010-03-07 16:45, Niall Pemberton wrote:
>>>>> On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg <dennisl@apache.org>
wrote:
>>>>>> On 2010-03-07 12:41, Niall Pemberton wrote:
>>>>>>> On Sat, Mar 6, 2010 at 12:15 AM, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>> The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to
me that the
>>>>>>>> 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.
>
> Does retiring legacy groupIds imply removing them from repository ? I
> don't think so, but would like to be sure. One of the important features
> in maven is to be able to reproduce builds long after the release. In my
> field, we sometimes need to maintain software for a very long time
> (think more than 20 years). Of course in our case we also use our own
> repositories, but I think other people may need a few years later to
> rebuild something despite they did not backup anything.
>
>>
>> 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.
>
> I would prefer to adopt the new groupIds as fast as possible, perhaps at
> major releases even if they don't break API, but this is not a strong
> statement from me.

This may be the end what we decide eventually but you understand that
this is going cause users pain when they get two copies of a component
in their classpath and they waste hours trying to work out why their
app no longer works. With redirects the answer will be simple - to
remove older versions from their local repository - but it is going to
cause pain.

Niall

> Luc
>
>>
>> Please commons ppl respond if you disagree with the statements
>> above.  Assuming we are in agreement, we can continue the discussion
>> on repository@
>>
>> 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:
>>>>
>>>> http://markmail.org/message/l3oezqvhehscm67l
>>>>
>>>> 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
>>>> org.apache.commons.io 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message