Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 73871 invoked from network); 10 Mar 2011 14:13:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Mar 2011 14:13:19 -0000 Received: (qmail 67358 invoked by uid 500); 10 Mar 2011 14:13:19 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 67296 invoked by uid 500); 10 Mar 2011 14:13:18 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 67288 invoked by uid 99); 10 Mar 2011 14:13:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Mar 2011 14:13:18 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.219.192.166] (HELO smtp.bredband2.com) (83.219.192.166) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Mar 2011 14:13:14 +0000 Received: from [192.168.0.3] (c-83-233-111-152.cust.bredband2.com [83.233.111.152]) (Authenticated sender: ed5133) by smtp.bredband2.com (Postfix) with ESMTPA id 0532C15F850 for ; Thu, 10 Mar 2011 15:12:52 +0100 (CET) Message-ID: <4D78DC65.4010007@apache.org> Date: Thu, 10 Mar 2011 15:12:53 +0100 From: Dennis Lundberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Commons Developers List Subject: Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml References: <20110309000212.70CC32388A66@eris.apache.org> <4D78D639.2010800@apache.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2011-03-10 15:01, sebb wrote: > On 10 March 2011 13:46, Dennis Lundberg wrote: >> On 2011-03-10 00:36, sebb wrote: >>> On 9 March 2011 12:01, Niall Pemberton wrote: >>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb wrote: >>>>> On 9 March 2011 10:30, Niall Pemberton wrote: >>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory wrote: >>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb wrote: >>>>>>> >>>>>>>> On 9 March 2011 02:31, Gary Gregory wrote: >>>>>>>>> Does having the old style of groupId mean that deploying will not work, >>>>>>>> per >>>>>>>>> http://wiki.apache.org/commons/UsingNexus#top >>>>>>>>> >>>>>>>>> "All Commons components that use the org.apache.commons groupId are >>>>>>>> already >>>>>>>>> set up to use Nexus." >>>>>>>>> >>>>>>>>> And if not... what happens? >>>>>>>> >>>>>>>> Nexus won't let you upload. >>>>>>>> >>>>>>>> Two options: >>>>>>>> - use the old methods. These can work, but are error prone. >>>>>>>> - use JIRA to request a Nexus entry for the project. >>>>>>>> >>>>>>>> >>>>>>> Ug, I cannot change the groupId because I cannot change the package. Codec >>>>>>> 1.5 fixes some long standing bugs introduced in 1.4. >>>>>> >>>>>> IMO our build system should never be the driving factor behind >>>>>> changing the package name. >>>>>> >>>>>>> If I change the groupId... Are we talking end of the Maven world or wasted >>>>>>> memory? >>>>>> >>>>>> No, potentially users could end up with two versions of codec on their >>>>>> classpath - if the dependency is inherited from other dependencies >>>>>> that use the different groupIds. They can resolve this easily by >>>>>> adding elements to their pom. >>>>> >>>>> But what if the dependency is from someone elses component? >>>>> Does that work? >>>> >>>> Yes, you do something like the following: >>>> >>>> >>>> >>>> org.apache.commons >>>> commons-codec >>>> 1.5 >>>> >>>> >>>> >>>> foo >>>> bar >>>> 3.1 >>>> >>>> >>>> commons-codec >>>> commons-codec >>>> >>>> >>>> >>>> >>>> >>>>>> A bit of a PITA, but not the >>>>>> end of the world. Ideally though you would put re-location poms in >>>>>> place for the old vesions of codec and move them to the new groupid. >>>>>> The downside to that is that if people have the old versions already >>>>>> locally, maven doesn't go back to the repo and misses the relocation. >>>>>> This is also easily resolved, by people removing those versions from >>>>>> the local maven repo. >>>>> >>>>> That should always be possible. >>>>> >>>>>> commons-email re-located to the new groupid quite a while ago and >>>>>> theres been no complaints so far - see: >>>>>> http://repo2.maven.org/maven2/commons-email/commons-email/1.1/ >>>>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/ >>>>>> >>>>>> Although there will be some pain, I think we should bite the bullet >>>>>> and relocate commons components. >>>>> >>>>> I'd like to see some testing first, especially before we relocate low >>>>> level components such as commons-logging. >>>> >>>> You can test away on commons-email - :) >>> >>> Have just tried it. There are only 3 proper versions of commons-email >>> (1.0, 1.1, 1.2) >>> Here is what I set up: >>> >>> module1 depends on o.a.c:c-mail:1.2 and module2 >>> module2 depends on c-mail:c-mail:1.1 and module3 >>> module3 depends on c-mail:c-mail:1.0 >>> >>> mvn dependency:build-classpath includes two copies of commons-email: >>> >>> D:\repository\commons-email\commons-email\1.0\commons-email-1.0.jar >>> D:\repository\org\apache\commons\commons-email\1.2\commons-email-1.2.jar >>> >>> Maven has eliminated c-mail:c-mail:1.1 because it has a relocation pom >>> which means it is regarded as the same as 1.2. >>> >>> c-mail:c-mail:1.0 does not have a relocation pom, so Maven thinks it >>> is a different component, and keeps it in the classpath. >>> >>> Yes, I could have excluded c-mail:1.0 in module1, but in general it >>> would not be at all obvious that there was a duplicate classpath >>> entry. >>> The order in which classes are referenced and loaded may vary, and >>> only some orderings may cause problems for an application. >>> Could be hard to track down such problems. >>> >>> == >>> >>> This makes sense now. >>> >>> Provided *all* old groupId versions have a relocation pom (and >>> provided that the local workspace is refreshed if necessary), then >>> clearly Maven does have the information needed to realise that the two >>> groupIds are the same. I don't understand why no-one replied with this >>> information when I asked on the mailing list. >> >> You are correct in your conclusions here. So in this regard relocation >> POMs do work. >> >> The real problem is that the policy of the central Maven repository >> prevents us from uploading relocation POMs for all old groupId version. >> >> This policy states that you cannot upload new variants of files that are >> already in the repository, i.e. we are not allowed to upload a new >> variant of the POM for commons-email:commons-email:1.0 that contains >> relocation information. >> >> The reasons for this are technical. Maven will download an artifact from >> the central repository into the local repository only one time. Once it >> has successfully done so it will never attempt to download it again. >> >> This means that even if we were allowed to update a new variant of >> commons-email:commons-email:1.0 with relocation info in it, users who >> have already downloaded commons-email:commons-email:1.0 will still use >> the old variant of the POM. What we would have now is a nightmare - the >> build would work correctly (only one version of commons-email in the >> classpath) on one machine but not on another (two versions of >> commons-email in the classpath). >> >> The policy of the central repository was put in place in order to have >> consistent builds across *all* machines. >> >>> In the case of Commons-email, the process was not actually followed, >>> so Maven does not eliminate the additional mail jar. >> >> The process was followed as far as it was allowed to. When 1.1 was >> released under the org.apache.commons groupId a relocation POM was >> uploaded at the old groupId for the *new* (1.1) version. But not for the >> *old* (1.0) version, because it is not allowed. >> >>> Commons-email had only one or two formal releases under the old >>> groupId, so the amount of work to be done was quite small. [Even so, >>> it was not all done]. >>> >>> For a component with lots of versions, it will take some while to >>> assemble all the required files, and it will take a while to upload >>> them. >>> So there is a chance that builds during the transition process will >>> fail. By careful sequencing of updates, it may be possible to reduce >>> the likelihood of failures, but I'm not sure it is possible to >>> eliminate them entirely. [Who wants to be responsible for relocating >>> commons-logging?] >>> >>> I'm not saying we should not change groupIds if we want, but I think >>> the single example of commons-email is insufficient to show that it >>> will be trouble-free unless a lot of care is taken when doing the >>> migration. >>> >>> Does anyone know if there is an automated process for doing this? >> >> It is not a matter of whether it can be done manually or automatically. >> Either way - it will not work, for the reasons I gave above. >> >> What we are left with is a compromise: when we release a binary >> incompatible version of a component, we change the package name and the >> groupId at the same time. This is not an ideal solution, but it works >> and it'll keep our users sane in the long run. > > OK, I see. > > So if we wish to change the groupId, we also have to change the > package name, because of the restriction placed on Maven Central > updates. > > Also the Maven Guide to relocation at: > > http://maven.apache.org/guides/mini/guide-relocation.html > > does not apply to Maven Central. > > That should be made very clear... Quite right, I've raised a JIRA issue so it isn't forgotten. http://jira.codehaus.org/browse/MNGSITE-134 > >>>> Niall >>>> >>>>>> Niall >>>>>> >>>>>> >>>>>>> I do not understand enough about the Maven guts to grok the consequences... >>>>>>> >>>>>>> Thanks in advance for any clarification. >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Reverting and will do for 2.0. >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb wrote: >>>>>>>>>>> >>>>>>>>>>> On 9 March 2011 00:02, wrote: >>>>>>>>>>>> Author: ggregory >>>>>>>>>>>> Date: Wed Mar 9 00:02:12 2011 >>>>>>>>>>>> New Revision: 1079608 >>>>>>>>>>>> >>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1079608&view=rev >>>>>>>>>>>> Log: >>>>>>>>>>>> Use org.apache.commons groupId >>>>>>>>>>> >>>>>>>>>>> If you change the groupId you'll probably need to change the package >>>>>>>>>>> name as well .. >>>>>>>>>>> >>>>>>>>>>> Otherwise Maven can add two copies of the jar to the classpath, which >>>>>>>>>>> is not good when there are two copies of the same classes. >>>>>>>>>>> >>>>>>>>>>>> Modified: >>>>>>>>>>>> commons/proper/codec/trunk/pom.xml >>>>>>>>>>>> >>>>>>>>>>>> Modified: commons/proper/codec/trunk/pom.xml >>>>>>>>>>>> URL: >>>>>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/pom.xml?rev=1079608&r1=1079607&r2=1079608&view=diff >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> ============================================================================== >>>>>>>>>>>> --- commons/proper/codec/trunk/pom.xml (original) >>>>>>>>>>>> +++ commons/proper/codec/trunk/pom.xml Wed Mar 9 00:02:12 2011 >>>>>>>>>>>> @@ -25,7 +25,7 @@ >>>>>>>>>>>> 18 >>>>>>>>>>>> >>>>>>>>>>>> 4.0.0 >>>>>>>>>>>> - commons-codec >>>>>>>>>>>> + org.apache.commons >>>>>>>>>>>> commons-codec >>>>>>>>>>>> 1.5-SNAPSHOT >>>>>>>>>>>> Commons Codec >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thank you, >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> http://garygregory.wordpress.com/ >>>>>>>>>> http://garygregory.com/ >>>>>>>>>> http://people.apache.org/~ggregory/ >>>>>>>>>> http://twitter.com/GaryGregory >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thank you, >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> http://garygregory.wordpress.com/ >>>>>>>>> http://garygregory.com/ >>>>>>>>> http://people.apache.org/~ggregory/ >>>>>>>>> http://twitter.com/GaryGregory >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thank you, >>>>>>> Gary >>>>>>> >>>>>>> http://garygregory.wordpress.com/ >>>>>>> http://garygregory.com/ >>>>>>> http://people.apache.org/~ggregory/ >>>>>>> http://twitter.com/GaryGregory >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>> >>> >> >> >> -- >> Dennis Lundberg >> >> --------------------------------------------------------------------- >> 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 > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org