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
>
>>>> 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