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 Thu, 10 Mar 2011 14:30:42 GMT
On 10 March 2011 14:12, Dennis Lundberg <dennisl@apache.org> wrote:
> On 2011-03-10 15:01, sebb 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.
>>
>> 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 <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
>>
>>
>
>
> --
> 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


Mime
View raw message