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 Fri, 11 Mar 2011 14:09:10 GMT
On 2011-03-10 23:24, Niall Pemberton wrote:
> On Thu, Mar 10, 2011 at 2:01 PM, sebb <sebbaz@gmail.com> wrote:
>> On 10 March 2011 13:46, Dennis Lundberg <dennisl@apache.org> wrote:
>>> On 2011-03-10 00:36, sebb wrote:
>>>> On 9 March 2011 12:01, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>>>>> On Wed, Mar 9, 2011 at 11:20 AM, sebb <sebbaz@gmail.com> wrote:
>>>>>> On 9 March 2011 10:30, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>>>>>>> On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>>> On Tue, Mar 8, 2011 at 9:34 PM, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>>
>>>>>>>>> On 9 March 2011 02:31, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>>>>> Does having the old style of groupId mean that deploying
will not work,
>>>>>>>>> per
>>>>>>>>>> http://wiki.apache.org/commons/UsingNexus#top
>>>>>>>>>>
>>>>>>>>>> "All Commons components that use the org.apache.commons
groupId are
>>>>>>>>> already
>>>>>>>>>> set up to use Nexus."
>>>>>>>>>>
>>>>>>>>>> And if not... what happens?
>>>>>>>>>
>>>>>>>>> Nexus won't let you upload.
>>>>>>>>>
>>>>>>>>> Two options:
>>>>>>>>> - use the old methods. These can work, but are error
prone.
>>>>>>>>> - use JIRA to request a Nexus entry for the project.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Ug, I cannot change the groupId because I cannot change the
package. Codec
>>>>>>>> 1.5 fixes some long standing bugs introduced in 1.4.
>>>>>>>
>>>>>>> IMO our build system should never be the driving factor behind
>>>>>>> changing the package name.
>>>>>>>
>>>>>>>> If I change the groupId... Are we talking end of the Maven
world or wasted
>>>>>>>> memory?
>>>>>>>
>>>>>>> No, potentially users could end up with two versions of codec
on their
>>>>>>> classpath - if the dependency is inherited from other dependencies
>>>>>>> that use the different groupIds. They can resolve this easily
by
>>>>>>> adding <exclude> elements to their pom.
>>>>>>
>>>>>> But what if the dependency is from someone elses component?
>>>>>> Does that work?
>>>>>
>>>>> Yes, you do something like the following:
>>>>>
>>>>> <dependencies>
>>>>>    <dependency>
>>>>>        <groupId>org.apache.commons</groupId>
>>>>>        <artifactId>commons-codec</artifactId>
>>>>>        <version>1.5</version>
>>>>>    </dependency>
>>>>>
>>>>>    <dependency>
>>>>>        <groupId>foo</groupId>
>>>>>        <artifactId>bar</artifactId>
>>>>>        <version>3.1</version>
>>>>>            <exclusions>
>>>>>                <exclusion>
>>>>>                    <groupId>commons-codec</groupId>
>>>>>                    <artifactId>commons-codec</artifactId>
>>>>>                </exclusion>
>>>>>            </exclusions>
>>>>>        </dependency>
>>>>> <dependencies>
>>>>>
>>>>>>> A bit of a PITA, but not the
>>>>>>> end of the world. Ideally though you would put re-location poms
in
>>>>>>> place for the old vesions of codec and move them to the new groupid.
>>>>>>> The downside to that is that if people have the old versions
already
>>>>>>> locally, maven doesn't go back to the repo and misses the relocation.
>>>>>>> This is also easily resolved, by people removing those versions
from
>>>>>>> the local maven repo.
>>>>>>
>>>>>> That should always be possible.
>>>>>>
>>>>>>> commons-email re-located to the new groupid quite a while ago
and
>>>>>>> theres been no complaints so far - see:
>>>>>>> http://repo2.maven.org/maven2/commons-email/commons-email/1.1/
>>>>>>> http://repo2.maven.org/maven2/org/apache/commons/commons-email/
>>>>>>>
>>>>>>> Although there will be some pain, I think we should bite the
bullet
>>>>>>> and relocate commons components.
>>>>>>
>>>>>> I'd like to see some testing first, especially before we relocate
low
>>>>>> level components such as commons-logging.
>>>>>
>>>>> You can test away on commons-email - :)
>>>>
>>>> Have just tried it. There are only 3 proper versions of commons-email
>>>> (1.0, 1.1, 1.2)
>>>> Here is what I set up:
>>>>
>>>> module1 depends on o.a.c:c-mail:1.2 and module2
>>>> module2 depends on c-mail:c-mail:1.1 and module3
>>>> module3 depends on c-mail:c-mail:1.0
>>>>
>>>> mvn dependency:build-classpath includes two copies of commons-email:
>>>>
>>>> D:\repository\commons-email\commons-email\1.0\commons-email-1.0.jar
>>>> D:\repository\org\apache\commons\commons-email\1.2\commons-email-1.2.jar
>>>>
>>>> Maven has eliminated c-mail:c-mail:1.1 because it has a relocation pom
>>>> which means it is regarded as the same as 1.2.
>>>>
>>>> c-mail:c-mail:1.0 does not have a relocation pom, so Maven thinks it
>>>> is a different component, and keeps it in the classpath.
>>>>
>>>> Yes, I could have excluded c-mail:1.0 in module1, but in general it
>>>> would not be at all obvious that there was a duplicate classpath
>>>> entry.
>>>> The order in which classes are referenced and loaded may vary, and
>>>> only some orderings may cause problems for an application.
>>>> Could be hard to track down such problems.
>>>>
>>>> ==
>>>>
>>>> This makes sense now.
>>>>
>>>> Provided *all* old groupId versions have a relocation pom (and
>>>> provided that the local workspace is refreshed if necessary), then
>>>> clearly Maven does have the information needed to realise that the two
>>>> groupIds are the same. I don't understand why no-one replied with this
>>>> information when I asked on the mailing list.
>>>
>>> You are correct in your conclusions here. So in this regard relocation
>>> POMs do work.
>>>
>>> The real problem is that the policy of the central Maven repository
>>> prevents us from uploading relocation POMs for all old groupId version.
>>>
>>> This policy states that you cannot upload new variants of files that are
>>> already in the repository, i.e. we are not allowed to upload a new
>>> variant of the POM for commons-email:commons-email:1.0 that contains
>>> relocation information.
>>>
>>> The reasons for this are technical. Maven will download an artifact from
>>> the central repository into the local repository only one time. Once it
>>> has successfully done so it will never attempt to download it again.
>>>
>>> This means that even if we were allowed to update a new variant of
>>> commons-email:commons-email:1.0 with relocation info in it, users who
>>> have already downloaded commons-email:commons-email:1.0 will still use
>>> the old variant of the POM. What we would have now is a nightmare - the
>>> build would work correctly (only one version of commons-email in the
>>> classpath) on one machine but not on another (two versions of
>>> commons-email in the classpath).
>>>
>>> The policy of the central repository was put in place in order to have
>>> consistent builds across *all* machines.
>>>
>>>> In the case of Commons-email, the process was not actually followed,
>>>> so Maven does not eliminate the additional mail jar.
>>>
>>> The process was followed as far as it was allowed to. When 1.1 was
>>> released under the org.apache.commons groupId a relocation POM was
>>> uploaded at the old groupId for the *new* (1.1) version. But not for the
>>> *old* (1.0) version, because it is not allowed.
>>>
>>>> Commons-email had only one or two formal releases under the old
>>>> groupId, so the amount of work to be done was quite small. [Even so,
>>>> it was not all done].
>>>>
>>>> For a component with lots of versions, it will take some while to
>>>> assemble all the required files, and it will take a while to upload
>>>> them.
>>>> So there is a chance that builds during the transition process will
>>>> fail. By careful sequencing of updates, it may be possible to reduce
>>>> the likelihood of failures, but I'm not sure it is possible to
>>>> eliminate them entirely. [Who wants to be responsible for relocating
>>>> commons-logging?]
>>>>
>>>> I'm not saying we should not change groupIds if we want, but I think
>>>> the single example of commons-email is insufficient to show that it
>>>> will be trouble-free unless a lot of care is taken when doing the
>>>> migration.
>>>>
>>>> Does anyone know if there is an automated process for doing this?
>>>
>>> It is not a matter of whether it can be done manually or automatically.
>>> Either way - it will not work, for the reasons I gave above.
>>>
>>> What we are left with is a compromise: when we release a binary
>>> incompatible version of a component, we change the package name and the
>>> groupId at the same time. This is not an ideal solution, but it works
>>> and it'll keep our users sane in the long run.
>>
>> OK, I see.
>>
>> So if we wish to change the groupId, we also have to change the
>> package name, because of the restriction placed on Maven Central
>> updates.
> 
> 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 <garydgregory@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Reverting and will do for 2.0.
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2011 at 8:00 PM, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9 March 2011 00:02,  <ggregory@apache.org>
wrote:
>>>>>>>>>>>>> Author: ggregory
>>>>>>>>>>>>> Date: Wed Mar  9 00:02:12 2011
>>>>>>>>>>>>> New Revision: 1079608
>>>>>>>>>>>>>
>>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1079608&view=rev
>>>>>>>>>>>>> Log:
>>>>>>>>>>>>> Use org.apache.commons groupId
>>>>>>>>>>>>
>>>>>>>>>>>> If you change the groupId you'll probably
need to change the package
>>>>>>>>>>>> name as well ..
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise Maven can add two copies of the
jar to the classpath, which
>>>>>>>>>>>> is not good when there are two copies of
the same classes.
>>>>>>>>>>>>
>>>>>>>>>>>>> Modified:
>>>>>>>>>>>>>    commons/proper/codec/trunk/pom.xml
>>>>>>>>>>>>>
>>>>>>>>>>>>> Modified: commons/proper/codec/trunk/pom.xml
>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>
>>>>>>>>> http://svn.apache.org/viewvc/commons/proper/codec/trunk/pom.xml?rev=1079608&r1=1079607&r2=1079608&view=diff
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> ==============================================================================
>>>>>>>>>>>>> --- commons/proper/codec/trunk/pom.xml
(original)
>>>>>>>>>>>>> +++ commons/proper/codec/trunk/pom.xml
Wed Mar  9 00:02:12 2011
>>>>>>>>>>>>> @@ -25,7 +25,7 @@
>>>>>>>>>>>>>     <version>18</version>
>>>>>>>>>>>>>   </parent>
>>>>>>>>>>>>>   <modelVersion>4.0.0</modelVersion>
>>>>>>>>>>>>> -  <groupId>commons-codec</groupId>
>>>>>>>>>>>>> +  <groupId>org.apache.commons</groupId>
>>>>>>>>>>>>>   <artifactId>commons-codec</artifactId>
>>>>>>>>>>>>>   <version>1.5-SNAPSHOT</version>
>>>>>>>>>>>>>   <name>Commons Codec</name>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> http://garygregory.wordpress.com/
>>>>>>>>>>> http://garygregory.com/
>>>>>>>>>>> http://people.apache.org/~ggregory/
>>>>>>>>>>> http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thank you,
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> http://garygregory.wordpress.com/
>>>>>>>>>> http://garygregory.com/
>>>>>>>>>> http://people.apache.org/~ggregory/
>>>>>>>>>> http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thank you,
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> http://garygregory.wordpress.com/
>>>>>>>> http://garygregory.com/
>>>>>>>> http://people.apache.org/~ggregory/
>>>>>>>> http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> 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