I am getting no action so far on: https://issues.apache.org/jira/browse/INFRA-3498 "Enable Nexus Access For Commons Codec"
Can people interested in [codec] vote for it please? Thank you, Gary On Thu, Mar 10, 2011 at 9:12 AM, 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 > > > > >>>> 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
