commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
Date Thu, 10 Mar 2011 13:52:42 GMT
On Mar 10, 2011, at 8:47, 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.

Great write ups. Thanks. I wonder what would happen if maven used OSGi...

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


Mime
View raw message