On 3/11/11 7:09 AM, Dennis Lundberg wrote: > On 2011-03-10 23:24, Niall Pemberton wrote: >> On Thu, Mar 10, 2011 at 2:01 PM, sebb <seb...@gmail.com> wrote: >>> On 10 March 2011 13:46, Dennis Lundberg <denn...@apache.org> wrote: >>>> On 2011-03-10 00:36, sebb wrote: >>>>> On 9 March 2011 12:01, Niall Pemberton <niall.pember...@gmail.com> wrote: >>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <seb...@gmail.com> wrote: >>>>>>> On 9 March 2011 10:30, Niall Pemberton <niall.pember...@gmail.com> >>>>>>> wrote: >>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>>> wrote: >>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <seb...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <garydgreg...@gmail.com> 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 <exclude> elements to their pom. >>>>>>> But what if the dependency is from someone elses component? >>>>>>> Does that work? >>>>>> Yes, you do something like the following: >>>>>> >>>>>> <dependencies> >>>>>> <dependency> >>>>>> <groupId>org.apache.commons</groupId> >>>>>> <artifactId>commons-codec</artifactId> >>>>>> <version>1.5</version> >>>>>> </dependency> >>>>>> >>>>>> <dependency> >>>>>> <groupId>foo</groupId> >>>>>> <artifactId>bar</artifactId> >>>>>> <version>3.1</version> >>>>>> <exclusions> >>>>>> <exclusion> >>>>>> <groupId>commons-codec</groupId> >>>>>> <artifactId>commons-codec</artifactId> >>>>>> </exclusion> >>>>>> </exclusions> >>>>>> </dependency> >>>>>> <dependencies> >>>>>> >>>>>>>> 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. >> No, no, no! We should never decide to do a package re-name because of >> the build tool. Package re-name should be a last resort and only be >> based on a choice to introduce binary incompatibility. The decision to >> change the groupid is secondary. > Yes, our current compromise means that we need to wait with changing the > groupId until we get an opportunity. In our case this happens when we > decide to make a binary incompatible release. We don't break binary > compatibility because we want to change the groupId. We do it because > the issues we want to solve with the code requires us to. This does > however give us the opportunity to change the groupId. +1 - it would be great to update http://commons.apache.org/releases/versioning.html to include information on maven groupId/artifactId management.
Phil >> Also seems to me that we could change >> the groupid on some components. Email did it and it hasn't been a big >> issue. So it may be appropriate for some components, even if its not >> for others. >> >> >> Niall >> >>> 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... >>> >>>>>> 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 >>>>>>>>>>> <garydgreg...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>>> Reverting and will do for 2.0. >>>>>>>>>>>> >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <seb...@gmail.com> wrote: >>>>>>>>>>>>> On 9 March 2011 00:02, <ggreg...@apache.org> 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 @@ >>>>>>>>>>>>>> <version>18</version> >>>>>>>>>>>>>> </parent> >>>>>>>>>>>>>> <modelVersion>4.0.0</modelVersion> >>>>>>>>>>>>>> - <groupId>commons-codec</groupId> >>>>>>>>>>>>>> + <groupId>org.apache.commons</groupId> >>>>>>>>>>>>>> <artifactId>commons-codec</artifactId> >>>>>>>>>>>>>> <version>1.5-SNAPSHOT</version> >>>>>>>>>>>>>> <name>Commons Codec</name> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> -- >>>> Dennis Lundberg >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
