Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 87295 invoked from network); 10 Mar 2011 22:19:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Mar 2011 22:19:13 -0000 Received: (qmail 3776 invoked by uid 500); 10 Mar 2011 22:19:13 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 3681 invoked by uid 500); 10 Mar 2011 22:19:13 -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 3673 invoked by uid 99); 10 Mar 2011 22:19:13 -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 22:19:13 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com designates 209.85.214.171 as permitted sender) Received: from [209.85.214.171] (HELO mail-iw0-f171.google.com) (209.85.214.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Mar 2011 22:19:09 +0000 Received: by iwr19 with SMTP id 19so2253931iwr.30 for ; Thu, 10 Mar 2011 14:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=eSOFdObcOPJpKRKMgno9nYC90ESqNBWiPYqg1dMOXkU=; b=RxDoM5i5PzqFLuJJyqa3a/6NfoS7PGZrJIH4SfKef2MkY/3+rtnf9JQkYIoDNrmDLn Ew3cif1shvbm7HVJhlcVkK8GFEnX5jFJXBySW4m6bIJa7aR39RvlMOvO9KDPAS4tgMvQ CpmI9pI92cpO6OFAy00LBqh3U8nxL/mAbtUCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=MJ/Eb9CGvQdKfNHf2IKltCJVM4US9aPHHvFPELvjXRVopAE66gdaaru/x1egywDYmg Jp/A3i+NMUh+BqQg8b3SuUXNiojwjRQ+xUU8/R5RVohkvW+r7y8uuRp58SKwIRQtDCyu i+3DUIE0tF/qNN72PkiDP/Y1+55INzSO0pbTA= MIME-Version: 1.0 Received: by 10.43.62.210 with SMTP id xb18mr88618icb.349.1299795528001; Thu, 10 Mar 2011 14:18:48 -0800 (PST) Received: by 10.43.134.138 with HTTP; Thu, 10 Mar 2011 14:18:47 -0800 (PST) In-Reply-To: <4D78D639.2010800@apache.org> References: <20110309000212.70CC32388A66@eris.apache.org> <4D78D639.2010800@apache.org> Date: Thu, 10 Mar 2011 22:18:47 +0000 Message-ID: Subject: Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml From: Niall Pemberton To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2011 at 1:46 PM, 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 wro= te: >>>>> 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 ar= e >>>>>>> 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 thei= r >>>>> 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: >>> >>> >>> =A0 =A0 >>> =A0 =A0 =A0 =A0org.apache.commons >>> =A0 =A0 =A0 =A0commons-codec >>> =A0 =A0 =A0 =A01.5 >>> =A0 =A0 >>> >>> =A0 =A0 >>> =A0 =A0 =A0 =A0foo >>> =A0 =A0 =A0 =A0bar >>> =A0 =A0 =A0 =A03.1 >>> =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0commons-codec >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0commons-codec >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 >>> >>> >>>>> 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. >> >> =3D=3D >> >> 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. Thanks Dennis. I didn't know or had forgotten that was the policy. Niall >>> Niall >>> >>>>> Niall >>>>> >>>>> >>>>>> I do not understand enough about the Maven guts to grok the conseque= nces... >>>>>> >>>>>> 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, =A0 wrote: >>>>>>>>>>> Author: ggregory >>>>>>>>>>> Date: Wed Mar =A09 00:02:12 2011 >>>>>>>>>>> New Revision: 1079608 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=3D1079608&view=3Drev >>>>>>>>>>> Log: >>>>>>>>>>> Use org.apache.commons groupId >>>>>>>>>> >>>>>>>>>> If you change the groupId you'll probably need to change the pac= kage >>>>>>>>>> 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: >>>>>>>>>>> =A0 =A0commons/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= =3D1079608&r1=3D1079607&r2=3D1079608&view=3Ddiff >>>>>>>>>>> >>>>>>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>>>>>>>> --- commons/proper/codec/trunk/pom.xml (original) >>>>>>>>>>> +++ commons/proper/codec/trunk/pom.xml Wed Mar =A09 00:02:12 20= 11 >>>>>>>>>>> @@ -25,7 +25,7 @@ >>>>>>>>>>> =A0 =A0 18 >>>>>>>>>>> =A0 >>>>>>>>>>> =A0 4.0.0 >>>>>>>>>>> - =A0commons-codec >>>>>>>>>>> + =A0org.apache.commons >>>>>>>>>>> =A0 commons-codec >>>>>>>>>>> =A0 1.5-SNAPSHOT >>>>>>>>>>> =A0 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