Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]

[Dennis Lundberg]

Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?

I really don't have a clue. Since I have not acted as release manager 
for any component, I haven't really done my homework on what the 
difference between the two is. I know about the M1 an M2 repos at 
ibiblio, and that there is some  sort of conversion between them, but 
don't know what it looks like at the Apache end.

Do you have any suggestions on which is better?


see below

On 6/7/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:

1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo

2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId

3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:

   <relocation>
     <groupId>org.apache.commons</groupId>
   </relocation>

If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
<message> ?

I never did.


4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?


m1 repo - wait
m2 repo - ping

OK



Is that correct so far?


When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.


no

OK


If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?

local is ok

Cool, I'll have a go at it, to see it I can get it right. It'll have to 
wait until this weekend though.



--
Dennis Lundberg

Carlos Sanchez wrote:
> You are right. This would involve copying all the old group sutff to
> the new group and add the relocation poms.
>
> On 6/7/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote:
>>
>> AFAIK there is a way in maven repo to "relocate" dependencies, so 
that a
>> POM for any commons can be published at commons-xxx groupId, that
>> "relocates" to org.apache.commons" groupId.
>>
>> Servletapi for example is now under "javax.servlet"
>> 
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom 

>>
>>
>> Using this, when maven2 search for the "latest" release of any commons
>> it will look at the relocated one.
>>
>> Torsten Curdt a écrit :
>> > Brett,
>> >
>> > any comments on this?
>> >
>> > cheers
>> > --
>> > Torsten
>> >
>> > On 6/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>> >> Brett, I did the test that you suggested.
>> >>
>> >> 1. Installed commons-lang 1.0.1 into my local repo with
>> >> groupId=org.apache.commons
>> >>
>> >> mvn install:install-file -DgroupId=org.apache.commons
>> >> -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
>> >> -Dfile=/path/to/commons-lang-1.0.1.jar
>> >>
>> >> 2. Created Maven 2 projects a, b and c with the dependencies 
mentioned
>> >> below.
>> >>
>> >> 3. Installed projects a and b into my local repo
>> >> mvn install
>> >>
>> >> 4. packaged project c as a war
>> >> mvn package
>> >>
>> >> The resulting war file includes both commons-lang-1.0.1.jar and
>> >> commons-lang-2.1.jar which was what you thought would happen.
>> >>
>> >> So this is bad, I guess. Anyone who uses commons components
>> transitively
>> >> in a Maven 2 environment are likely to be bitten by this. They must
>> keep
>> >> the same groupId for all commons-lang dependencies, as an 
example, in
>> >> the entire chain of transitive dependencies. I.e. they can't mix
>> >> groupId=commons-lang and groupId=org.apache.commons. This can be a
>> PITA
>> >> since some of the dependencies are most likely out of the 
projects own
>> >> control.
>> >>
>> >> What do you suggest we do? Should we wait with this relocation 
until a
>> >> version of Maven 2 is released that can handle these kind of
>> >> dependencies?
>> >>
>> >> --
>> >> Dennis Lundberg
>> >>
>> >> Brett Porter wrote:
>> >> > an extensive test should be something along the lines of:
>> >> >
>> >> > project A depends on commons-lang:commons-lang 2.1
>> >> > project B depends on o.a.c:commons-lang 1.0
>> >> > project C is a webapp that depends on A and B
>> >> >
>> >> > webapp should have only one commons-lang.
>> >> >
>> >> > You could do this with your own repository (and something 
completely
>> >> > artificial instead of commons-lang if it makes it easier).
>> >> >
>> >> > - Brett
>> >> >
>> >> > Dennis Lundberg wrote:
>> >> >> Hi Brett
>> >> >>
>> >> >> Sorry, I misunderstood you regarding when to do the testing. So,
>> no I
>> >> >> haven't done the test, yet. Can you elaborate a bit more on what
>> >> needs
>> >> >> to be tested? Perhaps you know of an artifact that has been
>> relocated
>> >> >> that we can have a look at, to see how they have done.
>> >
>> > 
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> This message contains information that may be privileged or
>> confidential and is the property of the Capgemini Group. It is
>> intended only for the person to whom it is addressed. If you are not
>> the intended recipient,  you are not authorized to read, print,
>> retain, copy, disseminate,  distribute, or use this message or any
>> part thereof. If you receive this  message in error, please notify the
>> sender immediately and delete all  copies of this message.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Dennis Lundberg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]