commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Thu, 10 Mar 2011 13:46:33 GMT
On 2011-03-10 00:36, sebb wrote:
> On 9 March 2011 12:01, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <sebbaz@gmail.com> wrote:
>>> On 9 March 2011 10:30, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <sebbaz@gmail.com> wrote:
>>>>>
>>>>>> On 9 March 2011 02:31, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>> Does having the old style of groupId mean that deploying will
not work,
>>>>>> per
>>>>>>> http://wiki.apache.org/commons/UsingNexus#top
>>>>>>>
>>>>>>> "All Commons components that use the org.apache.commons groupId
are
>>>>>> already
>>>>>>> set up to use Nexus."
>>>>>>>
>>>>>>> And if not... what happens?
>>>>>>
>>>>>> Nexus won't let you upload.
>>>>>>
>>>>>> Two options:
>>>>>> - use the old methods. These can work, but are error prone.
>>>>>> - use JIRA to request a Nexus entry for the project.
>>>>>>
>>>>>>
>>>>> Ug, I cannot change the groupId because I cannot change the package.
Codec
>>>>> 1.5 fixes some long standing bugs introduced in 1.4.
>>>>
>>>> IMO our build system should never be the driving factor behind
>>>> changing the package name.
>>>>
>>>>> If I change the groupId... Are we talking end of the Maven world or wasted
>>>>> memory?
>>>>
>>>> No, potentially users could end up with two versions of codec on their
>>>> classpath - if the dependency is inherited from other dependencies
>>>> that use the different groupIds. They can resolve this easily by
>>>> adding <exclude> elements to their pom.
>>>
>>> But what if the dependency is from someone elses component?
>>> Does that work?
>>
>> Yes, you do something like the following:
>>
>> <dependencies>
>>    <dependency>
>>        <groupId>org.apache.commons</groupId>
>>        <artifactId>commons-codec</artifactId>
>>        <version>1.5</version>
>>    </dependency>
>>
>>    <dependency>
>>        <groupId>foo</groupId>
>>        <artifactId>bar</artifactId>
>>        <version>3.1</version>
>>            <exclusions>
>>                <exclusion>
>>                    <groupId>commons-codec</groupId>
>>                    <artifactId>commons-codec</artifactId>
>>                </exclusion>
>>            </exclusions>
>>        </dependency>
>> <dependencies>
>>
>>>> A bit of a PITA, but not the
>>>> end of the world. Ideally though you would put re-location poms in
>>>> place for the old vesions of codec and move them to the new groupid.
>>>> The downside to that is that if people have the old versions already
>>>> locally, maven doesn't go back to the repo and misses the relocation.
>>>> This is also easily resolved, by people removing those versions from
>>>> the local maven repo.
>>>
>>> That should always be possible.
>>>
>>>> commons-email re-located to the new groupid quite a while ago and
>>>> theres been no complaints so far - see:
>>>> http://repo2.maven.org/maven2/commons-email/commons-email/1.1/
>>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/
>>>>
>>>> Although there will be some pain, I think we should bite the bullet
>>>> and relocate commons components.
>>>
>>> I'd like to see some testing first, especially before we relocate low
>>> level components such as commons-logging.
>>
>> You can test away on commons-email - :)
> 
> Have just tried it. There are only 3 proper versions of commons-email
> (1.0, 1.1, 1.2)
> Here is what I set up:
> 
> module1 depends on o.a.c:c-mail:1.2 and module2
> module2 depends on c-mail:c-mail:1.1 and module3
> module3 depends on c-mail:c-mail:1.0
> 
> mvn dependency:build-classpath includes two copies of commons-email:
> 
> D:\repository\commons-email\commons-email\1.0\commons-email-1.0.jar
> D:\repository\org\apache\commons\commons-email\1.2\commons-email-1.2.jar
> 
> Maven has eliminated c-mail:c-mail:1.1 because it has a relocation pom
> which means it is regarded as the same as 1.2.
> 
> c-mail:c-mail:1.0 does not have a relocation pom, so Maven thinks it
> is a different component, and keeps it in the classpath.
> 
> Yes, I could have excluded c-mail:1.0 in module1, but in general it
> would not be at all obvious that there was a duplicate classpath
> entry.
> The order in which classes are referenced and loaded may vary, and
> only some orderings may cause problems for an application.
> Could be hard to track down such problems.
> 
> ==
> 
> This makes sense now.
> 
> Provided *all* old groupId versions have a relocation pom (and
> provided that the local workspace is refreshed if necessary), then
> clearly Maven does have the information needed to realise that the two
> groupIds are the same. I don't understand why no-one replied with this
> information when I asked on the mailing list.

You are correct in your conclusions here. So in this regard relocation
POMs do work.

The real problem is that the policy of the central Maven repository
prevents us from uploading relocation POMs for all old groupId version.

This policy states that you cannot upload new variants of files that are
already in the repository, i.e. we are not allowed to upload a new
variant of the POM for commons-email:commons-email:1.0 that contains
relocation information.

The reasons for this are technical. Maven will download an artifact from
the central repository into the local repository only one time. Once it
has successfully done so it will never attempt to download it again.

This means that even if we were allowed to update a new variant of
commons-email:commons-email:1.0 with relocation info in it, users who
have already downloaded commons-email:commons-email:1.0 will still use
the old variant of the POM. What we would have now is a nightmare - the
build would work correctly (only one version of commons-email in the
classpath) on one machine but not on another (two versions of
commons-email in the classpath).

The policy of the central repository was put in place in order to have
consistent builds across *all* machines.

> In the case of Commons-email, the process was not actually followed,
> so Maven does not eliminate the additional mail jar.

The process was followed as far as it was allowed to. When 1.1 was
released under the org.apache.commons groupId a relocation POM was
uploaded at the old groupId for the *new* (1.1) version. But not for the
*old* (1.0) version, because it is not allowed.

> Commons-email had only one or two formal releases under the old
> groupId, so the amount of work to be done was quite small. [Even so,
> it was not all done].
> 
> For a component with lots of versions, it will take some while to
> assemble all the required files, and it will take a while to upload
> them.
> So there is a chance that builds during the transition process will
> fail. By careful sequencing of updates, it may be possible to reduce
> the likelihood of failures, but I'm not sure it is possible to
> eliminate them entirely. [Who wants to be responsible for relocating
> commons-logging?]
> 
> I'm not saying we should not change groupIds if we want, but I think
> the single example of commons-email is insufficient to show that it
> will be trouble-free unless a lot of care is taken when doing the
> migration.
> 
> Does anyone know if there is an automated process for doing this?

It is not a matter of whether it can be done manually or automatically.
Either way - it will not work, for the reasons I gave above.

What we are left with is a compromise: when we release a binary
incompatible version of a component, we change the package name and the
groupId at the same time. This is not an ideal solution, but it works
and it'll keep our users sane in the long run.

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


-- 
Dennis Lundberg

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


Mime
View raw message