commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Wed, 09 Mar 2011 23:36:25 GMT
On 9 March 2011 12:01, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 11:20 AM, sebb <sebbaz@gmail.com> wrote:
>> On 9 March 2011 10:30, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <garydgregory@gmail.com> wrote:
>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <sebbaz@gmail.com> wrote:
>>>>
>>>>> On 9 March 2011 02:31, Gary Gregory <garydgregory@gmail.com> wrote:
>>>>> > Does having the old style of groupId mean that deploying will not
work,
>>>>> per
>>>>> > http://wiki.apache.org/commons/UsingNexus#top
>>>>> >
>>>>> > "All Commons components that use the org.apache.commons groupId
are
>>>>> already
>>>>> > set up to use Nexus."
>>>>> >
>>>>> > And if not... what happens?
>>>>>
>>>>> Nexus won't let you upload.
>>>>>
>>>>> Two options:
>>>>> - use the old methods. These can work, but are error prone.
>>>>> - use JIRA to request a Nexus entry for the project.
>>>>>
>>>>>
>>>> Ug, I cannot change the groupId because I cannot change the package. Codec
>>>> 1.5 fixes some long standing bugs introduced in 1.4.
>>>
>>> IMO our build system should never be the driving factor behind
>>> changing the package name.
>>>
>>>> If I change the groupId... Are we talking end of the Maven world or wasted
>>>> memory?
>>>
>>> No, potentially users could end up with two versions of codec on their
>>> classpath - if the dependency is inherited from other dependencies
>>> that use the different groupIds. They can resolve this easily by
>>> adding <exclude> elements to their pom.
>>
>> But what if the dependency is from someone elses component?
>> Does that work?
>
> Yes, you do something like the following:
>
> <dependencies>
>    <dependency>
>        <groupId>org.apache.commons</groupId>
>        <artifactId>commons-codec</artifactId>
>        <version>1.5</version>
>    </dependency>
>
>    <dependency>
>        <groupId>foo</groupId>
>        <artifactId>bar</artifactId>
>        <version>3.1</version>
>            <exclusions>
>                <exclusion>
>                    <groupId>commons-codec</groupId>
>                    <artifactId>commons-codec</artifactId>
>                </exclusion>
>            </exclusions>
>        </dependency>
> <dependencies>
>
>>> A bit of a PITA, but not the
>>> end of the world. Ideally though you would put re-location poms in
>>> place for the old vesions of codec and move them to the new groupid.
>>> The downside to that is that if people have the old versions already
>>> locally, maven doesn't go back to the repo and misses the relocation.
>>> This is also easily resolved, by people removing those versions from
>>> the local maven repo.
>>
>> That should always be possible.
>>
>>> commons-email re-located to the new groupid quite a while ago and
>>> theres been no complaints so far - see:
>>> http://repo2.maven.org/maven2/commons-email/commons-email/1.1/
>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/
>>>
>>> Although there will be some pain, I think we should bite the bullet
>>> and relocate commons components.
>>
>> I'd like to see some testing first, especially before we relocate low
>> level components such as commons-logging.
>
> You can test away on commons-email - :)

Have just tried it. There are only 3 proper versions of commons-email
(1.0, 1.1, 1.2)
Here is what I set up:

module1 depends on o.a.c:c-mail:1.2 and module2
module2 depends on c-mail:c-mail:1.1 and module3
module3 depends on c-mail:c-mail:1.0

mvn dependency:build-classpath includes two copies of commons-email:

D:\repository\commons-email\commons-email\1.0\commons-email-1.0.jar
D:\repository\org\apache\commons\commons-email\1.2\commons-email-1.2.jar

Maven has eliminated c-mail:c-mail:1.1 because it has a relocation pom
which means it is regarded as the same as 1.2.

c-mail:c-mail:1.0 does not have a relocation pom, so Maven thinks it
is a different component, and keeps it in the classpath.

Yes, I could have excluded c-mail:1.0 in module1, but in general it
would not be at all obvious that there was a duplicate classpath
entry.
The order in which classes are referenced and loaded may vary, and
only some orderings may cause problems for an application.
Could be hard to track down such problems.

==

This makes sense now.

Provided *all* old groupId versions have a relocation pom (and
provided that the local workspace is refreshed if necessary), then
clearly Maven does have the information needed to realise that the two
groupIds are the same. I don't understand why no-one replied with this
information when I asked on the mailing list.

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 <garydgregory@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Reverting and will do for 2.0.
>>>>> >>
>>>>> >> Gary
>>>>> >>
>>>>> >> On Tue, Mar 8, 2011 at 8:00 PM, sebb <sebbaz@gmail.com>
wrote:
>>>>> >>>
>>>>> >>> On 9 March 2011 00:02,  <ggregory@apache.org> wrote:
>>>>> >>> > Author: ggregory
>>>>> >>> > Date: Wed Mar  9 00:02:12 2011
>>>>> >>> > New Revision: 1079608
>>>>> >>> >
>>>>> >>> > URL: http://svn.apache.org/viewvc?rev=1079608&view=rev
>>>>> >>> > Log:
>>>>> >>> > Use org.apache.commons groupId
>>>>> >>>
>>>>> >>> If you change the groupId you'll probably need to change
the package
>>>>> >>> name as well ..
>>>>> >>>
>>>>> >>> Otherwise Maven can add two copies of the jar to the classpath,
which
>>>>> >>> is not good when there are two copies of the same classes.
>>>>> >>>
>>>>> >>> > Modified:
>>>>> >>> >    commons/proper/codec/trunk/pom.xml
>>>>> >>> >
>>>>> >>> > Modified: commons/proper/codec/trunk/pom.xml
>>>>> >>> > URL:
>>>>> >>> >
>>>>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/pom.xml?rev=1079608&r1=1079607&r2=1079608&view=diff
>>>>> >>> >
>>>>> >>> >
>>>>> ==============================================================================
>>>>> >>> > --- commons/proper/codec/trunk/pom.xml (original)
>>>>> >>> > +++ commons/proper/codec/trunk/pom.xml Wed Mar  9
00:02:12 2011
>>>>> >>> > @@ -25,7 +25,7 @@
>>>>> >>> >     <version>18</version>
>>>>> >>> >   </parent>
>>>>> >>> >   <modelVersion>4.0.0</modelVersion>
>>>>> >>> > -  <groupId>commons-codec</groupId>
>>>>> >>> > +  <groupId>org.apache.commons</groupId>
>>>>> >>> >   <artifactId>commons-codec</artifactId>
>>>>> >>> >   <version>1.5-SNAPSHOT</version>
>>>>> >>> >   <name>Commons Codec</name>
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>>
>>>>> >>> ---------------------------------------------------------------------
>>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Thank you,
>>>>> >> Gary
>>>>> >>
>>>>> >> http://garygregory.wordpress.com/
>>>>> >> http://garygregory.com/
>>>>> >> http://people.apache.org/~ggregory/
>>>>> >> http://twitter.com/GaryGregory
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Thank you,
>>>>> > Gary
>>>>> >
>>>>> > http://garygregory.wordpress.com/
>>>>> > http://garygregory.com/
>>>>> > http://people.apache.org/~ggregory/
>>>>> > http://twitter.com/GaryGregory
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you,
>>>> Gary
>>>>
>>>> http://garygregory.wordpress.com/
>>>> http://garygregory.com/
>>>> http://people.apache.org/~ggregory/
>>>> http://twitter.com/GaryGregory
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message