commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Fri, 11 Mar 2011 16:28:39 GMT
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 <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.
+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
<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
>>
>>
>


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


Mime
View raw message