You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2011/03/09 02:00:37 UTC
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Mar 9, 2011 at 5:47 AM, Jochen Wiedmann
<jo...@gmail.com>wrote:
> It only means that you might have to create a Jira issue which
> requests Nexus permissions for the groupId commons-codec. Quite
> possible that this already exists. For example, I can say for sure
> that such permissions exist for commons-fileupload. Just try to deploy
> to Nexus and if you get suspicious error messages that sound like
> authorization problems, create the issue.
>
> JIRA ticket is here: https://issues.apache.org/jira/browse/INFRA-3498
Gary
> Jochen
>
>
> On Wed, Mar 9, 2011 at 3:31 AM, Gary Gregory <ga...@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?
> >
> > Gary
> >
> >
> > On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 9 March 2011 00:02, <gg...@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
> >
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Jochen Wiedmann <jo...@gmail.com>.
It only means that you might have to create a Jira issue which
requests Nexus permissions for the groupId commons-codec. Quite
possible that this already exists. For example, I can say for sure
that such permissions exist for commons-fileupload. Just try to deploy
to Nexus and if you get suspicious error messages that sound like
authorization problems, create the issue.
Jochen
On Wed, Mar 9, 2011 at 3:31 AM, Gary Gregory <ga...@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?
>
> Gary
>
>
> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 March 2011 00:02, <gg...@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
>
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
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?
Gary
On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 02:31, Gary Gregory <ga...@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.
>
Which is what commons-net did? I see 3.0-SNAPHOTS here:
https://repository.apache.org/content/repositories/snapshots/commons-net/
Gary
>
> > Gary
> >
> > On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> Reverting and will do for 2.0.
> >>
> >> Gary
> >>
> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
Thank you, I understand now. I will go the Nexus route first...
Gary
On Tue, Mar 8, 2011 at 10:55 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 02:46, Gary Gregory <ga...@gmail.com> wrote:
> >
> >
> > On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
> >>
> >> On 9 March 2011 02:31, Gary Gregory <ga...@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.
> >
> > If I change the groupId... Are we talking end of the Maven world or
> wasted
> > memory?
>
> Neither.
>
> > I do not understand enough about the Maven guts to grok the
> consequences...
>
> Maven uses the groupId:artifactId tuple to decide if two components
> are the same.
>
> So if VFS depends on c-logging:1 and NET:2 and NET:2 uses
> c-logging:2.1 Maven will add only logging:2.1 to the classpath.
>
> But if c-logging:2.1 has a different groupId - e.g. o.a.c-logging -
> from c-logging:1, both will end up on the classpath. Not good.
>
> Now there is a relocation POM which is supposed to tell Maven that
> c-logging is the same as o.a.c-logging.
> However, the relocation is stored only under original groupId, and
> AFAIK only on the latest version.
>
> For the relocation to work, Maven would have to read all the poms.
> In the example above, it would have to start with c-logging:1, and
> find the relocation pom in (say) c-logging:1.13.
>
> I tried to find out if Maven does this, but noone on the Maven list
> could say for sure.
> I suspect not, because local workspaces don't have poms apart from the
> ones that have been directly referenced.
> The info needs to be in the local workspace otherwise offline mode won't
> work.
>
> I have not found time to test how /if it works. I think this will
> require a released component with a relocation pom, plus several dummy
> projects that use versions either side of the relocation. Then a test
> to show the classpath. Then delete the local copy of the relocation
> pom and see if Maven finds it.
>
> The same considerations apply to changing the artifactId.
>
>
> > Thanks in advance for any clarification.
> >
> > Gary
> >
> >>
> >> > Gary
> >> >
> >> > On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Reverting and will do for 2.0.
> >> >>
> >> >> Gary
> >> >>
> >> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> >> >>>
> >> >>> On 9 March 2011 00:02, <gg...@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
> >
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Sebb,
sebb wrote:
> On 9 March 2011 02:46, Gary Gregory <ga...@gmail.com> wrote:
[snip]
>> Ug, I cannot change the groupId because I cannot change the package.
>> Codec 1.5 fixes some long standing bugs introduced in 1.4.
>>
>> If I change the groupId... Are we talking end of the Maven world or
>> wasted memory?
>
> Neither.
>
>> I do not understand enough about the Maven guts to grok the
>> consequences...
>
> Maven uses the groupId:artifactId tuple to decide if two components
> are the same.
>
> So if VFS depends on c-logging:1 and NET:2 and NET:2 uses
> c-logging:2.1 Maven will add only logging:2.1 to the classpath.
>
> But if c-logging:2.1 has a different groupId - e.g. o.a.c-logging -
> from c-logging:1, both will end up on the classpath. Not good.
>
> Now there is a relocation POM which is supposed to tell Maven that
> c-logging is the same as o.a.c-logging.
> However, the relocation is stored only under original groupId, and
> AFAIK only on the latest version.
No, you can (and should) add a relocation pom for all new versions.
> For the relocation to work, Maven would have to read all the poms.
> In the example above, it would have to start with c-logging:1, and
> find the relocation pom in (say) c-logging:1.13.
It does not! It's no proactive task. They are only considered if someone
uses the new version with the old groupId, then - and only then - will Maven
recognize that it looks for the same artifact. Say, you can setup a
dependencyManagement section in your POM and use the new version for the old
and new G:A:V scalar, then this works as expected. But it means that a
relocation for the new version must exist.
> I tried to find out if Maven does this, but noone on the Maven list
> could say for sure.
No wonder, because its limitation is serious and the feature is more or less
unused now.
> I suspect not, because local workspaces don't have poms apart from the
> ones that have been directly referenced.
Correct assumption.
> The info needs to be in the local workspace otherwise offline mode won't
> work.
No, you have Maven to point to a version that has a relocation like in the
scenario above with the depMgmt section.
> I have not found time to test how /if it works. I think this will
> require a released component with a relocation pom, plus several dummy
> projects that use versions either side of the relocation. Then a test
> to show the classpath. Then delete the local copy of the relocation
> pom and see if Maven finds it.
>
> The same considerations apply to changing the artifactId.
It's not worth the time, simply avoid it and Gary should keep the old
groupId unless we break the API in a way we need a different package name.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 9 March 2011 02:46, Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>
>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
>
> If I change the groupId... Are we talking end of the Maven world or wasted
> memory?
Neither.
> I do not understand enough about the Maven guts to grok the consequences...
Maven uses the groupId:artifactId tuple to decide if two components
are the same.
So if VFS depends on c-logging:1 and NET:2 and NET:2 uses
c-logging:2.1 Maven will add only logging:2.1 to the classpath.
But if c-logging:2.1 has a different groupId - e.g. o.a.c-logging -
from c-logging:1, both will end up on the classpath. Not good.
Now there is a relocation POM which is supposed to tell Maven that
c-logging is the same as o.a.c-logging.
However, the relocation is stored only under original groupId, and
AFAIK only on the latest version.
For the relocation to work, Maven would have to read all the poms.
In the example above, it would have to start with c-logging:1, and
find the relocation pom in (say) c-logging:1.13.
I tried to find out if Maven does this, but noone on the Maven list
could say for sure.
I suspect not, because local workspaces don't have poms apart from the
ones that have been directly referenced.
The info needs to be in the local workspace otherwise offline mode won't work.
I have not found time to test how /if it works. I think this will
require a released component with a relocation pom, plus several dummy
projects that use versions either side of the relocation. Then a test
to show the classpath. Then delete the local copy of the relocation
pom and see if Maven finds it.
The same considerations apply to changing the artifactId.
> Thanks in advance for any clarification.
>
> Gary
>
>>
>> > Gary
>> >
>> > On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com>
>> > wrote:
>> >>
>> >> Reverting and will do for 2.0.
>> >>
>> >> Gary
>> >>
>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>> >>>
>> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
Yep, fine with me, waiting on
https://issues.apache.org/jira/browse/INFRA-3498
Gary
On Wed, Mar 9, 2011 at 9:17 AM, Jochen Wiedmann
<jo...@gmail.com>wrote:
> Please, let's forget about the relocation nonsense. Noone ever said
> it'd be working as expected (for example. sebb has tried heavily to
> get that confirmed on maven-dev) and it will only break things for
> other users without real gain. After all, what's so terrible if the
> group ID isn't what we'd like to see?
>
> It makes sense to change the groupId when binary incompatibilities are
> intentional (in other words, if the package changes). But that's all I
> can see.
>
>
> On Wed, Mar 9, 2011 at 12:20 PM, sebb <se...@gmail.com> wrote:
> > On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com>
> wrote:
> >> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>>> On 9 March 2011 02:31, Gary Gregory <ga...@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?
> >
> >> 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.
> >
> >> 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 <se...@gmail.com> wrote:
> >>>> >>>
> >>>> >>> On 9 March 2011 00:02, <gg...@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
> >
> >
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 9, 2011, at 16:04, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 2:17 PM, Jochen Wiedmann
> <jo...@gmail.com> wrote:
>> Please, let's forget about the relocation nonsense. Noone ever said
>> it'd be working as expected (for example. sebb has tried heavily to
>> get that confirmed on maven-dev) and it will only break things for
>> other users without real gain. After all, what's so terrible if the
>> group ID isn't what we'd like to see?
>
> Its not so terrible, but its also not nonsense and AFAIK the pain is
> minimal and easily fixed. There also hasn't been a single complaint I
> remember in the 2+ years since commons-email did this.
>
So your are saying just go ahead and change it? So far I have not seen
any action on the Jira I created yesterday. I do not know how big of a
deal it is to create whatever is needed in nexus.
Gary
> Niall
>
>> It makes sense to change the groupId when binary incompatibilities are
>> intentional (in other words, if the package changes). But that's all I
>> can see.
>>
>>
>> On Wed, Mar 9, 2011 at 12:20 PM, sebb <se...@gmail.com> wrote:
>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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?
>>>
>>>> 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.
>>>
>>>> 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 <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>>>
>>>
>>
>>
>>
>> --
>> I Am What I Am And That's All What I Yam (Popeye)
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Mar 9, 2011 at 2:17 PM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> Please, let's forget about the relocation nonsense. Noone ever said
> it'd be working as expected (for example. sebb has tried heavily to
> get that confirmed on maven-dev) and it will only break things for
> other users without real gain. After all, what's so terrible if the
> group ID isn't what we'd like to see?
Its not so terrible, but its also not nonsense and AFAIK the pain is
minimal and easily fixed. There also hasn't been a single complaint I
remember in the 2+ years since commons-email did this.
Niall
> It makes sense to change the groupId when binary incompatibilities are
> intentional (in other words, if the package changes). But that's all I
> can see.
>
>
> On Wed, Mar 9, 2011 at 12:20 PM, sebb <se...@gmail.com> wrote:
>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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?
>>
>>> 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.
>>
>>> 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 <ga...@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Reverting and will do for 2.0.
>>>>> >>
>>>>> >> Gary
>>>>> >>
>>>>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>> >>>
>>>>> >>> On 9 March 2011 00:02, <gg...@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
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Jochen Wiedmann <jo...@gmail.com>.
Please, let's forget about the relocation nonsense. Noone ever said
it'd be working as expected (for example. sebb has tried heavily to
get that confirmed on maven-dev) and it will only break things for
other users without real gain. After all, what's so terrible if the
group ID isn't what we'd like to see?
It makes sense to change the groupId when binary incompatibilities are
intentional (in other words, if the package changes). But that's all I
can see.
On Wed, Mar 9, 2011 at 12:20 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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?
>
>> 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.
>
>> 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 <ga...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> Reverting and will do for 2.0.
>>>> >>
>>>> >> Gary
>>>> >>
>>>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>> >>>
>>>> >>> On 9 March 2011 00:02, <gg...@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
>
>
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Mar 10, 2011 at 1:46 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2011-03-10 00:36, sebb wrote:
>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
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 consequences...
>>>>>>
>>>>>> Thanks in advance for any clarification.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
On Mar 10, 2011, at 8:47, Dennis Lundberg <de...@apache.org> wrote:
> On 2011-03-10 00:36, sebb wrote:
>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
Great write ups. Thanks. I wonder what would happen if maven used OSGi...
Gary
>
>>> 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 <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 10 March 2011 14:12, Dennis Lundberg <de...@apache.org> wrote:
> On 2011-03-10 15:01, sebb wrote:
>> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2011-03-10 00:36, sebb wrote:
>>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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 <ga...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
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 <de...@apache.org> wrote:
> On 2011-03-10 15:01, sebb wrote:
> > On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
> >> On 2011-03-10 00:36, sebb wrote:
> >>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com>
> wrote:
> >>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
> >>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@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 <se...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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 <se...@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Dennis Lundberg <de...@apache.org>.
On 2011-03-10 15:01, sebb wrote:
> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>> On 2011-03-10 00:36, sebb wrote:
>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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 <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 10 March 2011 22:24, Niall Pemberton <ni...@gmail.com> wrote:
> On Thu, Mar 10, 2011 at 2:01 PM, sebb <se...@gmail.com> wrote:
>> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2011-03-10 00:36, sebb wrote:
>>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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. Also seems to me that we could change
> the groupid on some components. Email did it and it hasn't been a big
> issue.
Email is not a very high use component; there was only one previous
release using the old Maven name (and as far as I can tell it could
not easily be used from Maven anyway because some of its dependencies
were not in Maven), and there was a relocation pom for the second
release.
> So it may be appropriate for some components, even if its not for others.
Agreed. I think it would be a big mistake to change e.g. commons-logging.
Maven is not just a build tool - it is also used to distribute jars to
other projects.
If we just change the groupId/artifactId without changing package
name, then it will likely cause grief for other users.
Equally, if we change package name without changing groupId/artifactId
this will cause grief for others.
We can look at it the other way round:
We don't want to change package name - that implies Maven community
will have to agree to continue using the same groupId/artifactId, even
if they don't like it.
If we do want to change package name, the Maven community will be
forced to use a new groupId/artifactId.
The groupId/artifactId are purely Maven constructs, so we should use
whatever settiings are necessary to ensure our software can be used
without difficulty.
>
> 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 <ga...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Phil Steitz <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
>>> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>>>> On 2011-03-10 00:36, sebb wrote:
>>>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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 <ga...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Dennis Lundberg <de...@apache.org>.
On 2011-03-10 23:24, Niall Pemberton wrote:
> On Thu, Mar 10, 2011 at 2:01 PM, sebb <se...@gmail.com> wrote:
>> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2011-03-10 00:36, sebb wrote:
>>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
> 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 <ga...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Mar 10, 2011 at 2:01 PM, sebb <se...@gmail.com> wrote:
> On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
>> On 2011-03-10 00:36, sebb wrote:
>>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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. 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 <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 10 March 2011 13:46, Dennis Lundberg <de...@apache.org> wrote:
> On 2011-03-10 00:36, sebb wrote:
>> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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...
>>> 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 <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Dennis Lundberg <de...@apache.org>.
On 2011-03-10 00:36, sebb wrote:
> On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
>> 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 <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 9 March 2011 12:01, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 11:20 AM, sebb <se...@gmail.com> wrote:
>> On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 9 March 2011 02:31, Gary Gregory <ga...@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.
In the case of Commons-email, the process was not actually followed,
so Maven does not eliminate the additional mail jar.
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?
> 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 <ga...@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Reverting and will do for 2.0.
>>>>> >>
>>>>> >> Gary
>>>>> >>
>>>>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>>> >>>
>>>>> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 9 March 2011 10:30, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 9 March 2011 02:31, Gary Gregory <ga...@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?
> 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.
> 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 <ga...@gmail.com>
>>> wrote:
>>> >>
>>> >> Reverting and will do for 2.0.
>>> >>
>>> >> Gary
>>> >>
>>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>> >>>
>>> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 March 2011 02:31, Gary Gregory <ga...@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. 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.
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.
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 <ga...@gmail.com>
>> wrote:
>> >>
>> >> Reverting and will do for 2.0.
>> >>
>> >> Gary
>> >>
>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>> >>>
>> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 8, 2011 at 9:34 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 02:31, Gary Gregory <ga...@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.
If I change the groupId... Are we talking end of the Maven world or wasted
memory?
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 <ga...@gmail.com>
> wrote:
> >>
> >> Reverting and will do for 2.0.
> >>
> >> Gary
> >>
> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by sebb <se...@gmail.com>.
On 9 March 2011 02:31, Gary Gregory <ga...@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.
> Gary
>
> On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Reverting and will do for 2.0.
>>
>> Gary
>>
>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On 9 March 2011 00:02, <gg...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
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?
Gary
On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory <ga...@gmail.com> wrote:
> Reverting and will do for 2.0.
>
> Gary
>
> On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 March 2011 00:02, <gg...@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
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Posted by Gary Gregory <ga...@gmail.com>.
Reverting and will do for 2.0.
Gary
On Tue, Mar 8, 2011 at 8:00 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2011 00:02, <gg...@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