Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B94205E.2010604@free.fr>
Date: Sun, 07 Mar 2010 22:53:34 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [all] Changing maven groupIDs  [WAS:  [IO] Next version of IO
 - should this be 2.0?]
References: <25aac9fc1003051615n6fc2382w9fc285f8aa796915@mail.gmail.com>
	 <55afdc851003070341o5f7d895ai13cd748346f630b4@mail.gmail.com>
	 <4B93C614.4040707@apache.org>
	 <55afdc851003070745yad0bb37v47b28a855e9e796b@mail.gmail.com>
	 <4B93E255.8000203@apache.org>
 <55afdc851003070941g408142e3ld93280677fe3e6f0@mail.gmail.com>
 <4B94148D.4080005@gmail.com>
In-Reply-To: <4B94148D.4080005@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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.

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
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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