On 10 March 2011 14:12, Dennis Lundberg <denn...@apache.org> wrote: > On 2011-03-10 15:01, sebb 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. >> >> 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
Thanks! >> >>>>> 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 >> >> > > > -- > 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
