commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Thu, 10 Mar 2011 14:23:06 GMT
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 <dennisl@apache.org> wrote:

> On 2011-03-10 15:01, sebb wrote:
> > On 10 March 2011 13:46, Dennis Lundberg <dennisl@apache.org> wrote:
> >> On 2011-03-10 00:36, sebb wrote:
> >>> On 9 March 2011 12:01, Niall Pemberton <niall.pemberton@gmail.com>
> wrote:
> >>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <sebbaz@gmail.com> wrote:
> >>>>> On 9 March 2011 10:30, Niall Pemberton <niall.pemberton@gmail.com>
> wrote:
> >>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <
> garydgregory@gmail.com> wrote:
> >>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <sebbaz@gmail.com>
wrote:
> >>>>>>>
> >>>>>>>> On 9 March 2011 02:31, Gary Gregory <garydgregory@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 <
> garydgregory@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Reverting and will do for 2.0.
> >>>>>>>>>>
> >>>>>>>>>> Gary
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <sebbaz@gmail.com>
wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 9 March 2011 00:02,  <ggregory@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-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
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message