History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: HAUS-1309
Type: Task Task
Status: Reopened Reopened
Priority: Critical Critical
Assignee: Unassigned
Reporter: Joerg Schaible
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Haus Chores

Cannot relocate M1 artifacts, resp. cannot use current M1 recommendation for groupId

Created: 29/Aug/06 02:38 AM   Updated: 14/Nov/06 11:19 AM
Component/s: Xircles
Affects Version/s: short-term
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
dependent
 


 Description  « Hide
Hi folks,

we have used M2 for the first time of an XStream release and also switched the groupId from "xstream" to the now recommended form "com.thoughtworks.xstream". According the relocation guide http://maven.apache.org/guides/mini/guide-relocation.html we should now move all the old artifacts in the M1 repo from "xstream" to "com.thoughtworks.xstream", but we cannot do this! The current setup for the M1 repo at Codehaus has a fixed mapping from the project name to the groupId, since the webdav allows only access to "dav.codehaus.org/dist/xstream", but not to "dav.codehaus.org/dist/com.thoughtworks.xstream". And note, that the second form for is now recommended even for M1 starting new projects.

To follow the relocation guide we need access to both locations! So it seems the management client should also allow the groupId for M1 to be chosen and also allow access to legacy groupIds (this might also happen for M2 projects ....).

The situation is critical though, since the automated repo sync to ibiblio created now the situation, that the xstream-1.2 release is available two times (with groupId "xstream" and with "com.thoughtworks.xstream"), but only the 2nd artifact has a proper POM.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Ben Walding - 29/Aug/06 05:09 AM
Are you going to be releasing more items into http://dist.codehaus.org/com.thoughtworks.xstream ?

Are you going to be releasing more items into http://dist.codehaus.org/xstream ?


Brett Porter - 29/Aug/06 05:17 AM
you should only need to depoy to the m2 repo, avoiding the duplicates. m1 will be able to read com.tw.xstream from ibiblio once synced.

However, it is correct that you will need access to the other locations to do the relocating.


Joerg Schaible - 29/Aug/06 05:27 AM
@Ben:
com.thoughtworks.xstream although we will release at some time XStream 2.x with groupId org.codehaus.xstream (because this will not be a replacement of the 1.x series) i.e. we will have two groupIds: one for maintenance releases of the 1.x branch and the other one for 2.x. But we are able to switch already by changing the M2 groupId in Xircles.

@Brett:
I was ignorant to the fact, that M1 can access the M2 repo. So what is best to deal with the situation? Shall we remove the xstream-1.2.jar from the M1 repo and will the sync remove it from ibiblio also? And as you've commented, this does not help with the relocations ...

  • Jörg

Joerg Schaible - 15/Sep/06 06:01 AM
Any update on this? It would be nice if the location of the M1 repo would also use the (dotted) groupId. The we could at least tweak the value temporarily to make the necessary adjustments.

Ben Walding - 15/Sep/06 06:28 AM
I have relinked your M1 distribution site such that you can access it via:

http://dist.codehaus.org/com.thoughtworks.xstream/
http://dist.codehaus.org/xstream/

In regards to flipping repository ids around; you can't. We fixed that in a recent release because it was subject to abuse. However I think you can still release artifacts under either of the two repository ids.


Joerg Schaible - 15/Sep/06 07:10 AM
Sorry, Ben, this is not gonna work. The files will not have identical content! The POM files in the old location must have the relocation entry while the ones in the new location may not have 'em.

Ben Walding - 15/Sep/06 07:35 AM
Are you talking about m1 or m2?

if m2 - you've got two separate trees.
if m1 - does m1 use poms? you don't have any in there at present.


Joerg Schaible - 15/Sep/06 07:47 AM
Both. We had all our releases up to version 1.2 in the Maven 1 repository. Starting with XStream 1.2 we're supporting M2, but we also have changed our groupId to the M2 standard. Therefore we have to move the old artifacts to the new location m1-repo/xstream -> m2-repo/com.thoughtworks.xstream and create at the old location POMs with relocation entries. See the pointer to the relocation guide in the issue's description.

Ben Walding - 15/Sep/06 07:58 AM
Yes, and what I've given you supports this as far as I can tell.

You've got 3 places to put things

m1 location - which will show up as /xstream and /com.thoughtworks.xstream (no POMs in here afaik)

m2 location A - /com/thoughtworks/xstream (old xstream 1.X stuff)
m2 location B - /org/codehaus/xstream (new xstream 1.2 stuff)


Joerg Schaible - 15/Sep/06 09:14 AM
What we need:
  • /xstream - should have POMs with relocations for XStream < 1.2
  • /com.thoughtworks.xstream - moved stuff from /xstream, POMs (without relocations) may be added
  • /com/thoughtworks/xstream - stuff for XStream >= 1.2 ---> will be mapped automatically to /com.thoughtworks.xstream my Maven (not physically)
  • /org/codehaus/xstream - XStream >= 2.x future XStream stuff, incompatible API to previous versions

Reasoning:
M2 recommends strongly to use the package name as groupId. This has already installed for other projects, e.g. the complete Sun stuff, Maven itself, Spring, and a lot more. Even Jakarta commons is about to switch. Beginning with XStream 1.2 we took therefore com.thoughtworks.xstream as groupId, since it's XStreams package name. Any maintenance releases for the 1.2 branch will use this groupId. Starting with XStream 2.0 we use a different groupId, since our API will be incompatible and we want to allow both versions of XStream in the classpath. Since development of XStream 2.x and maintenance of XStream 1.2..x will happen at same time, all locations will be in use:

  • /xstream: since we have to add also for newer versions relocating POMs
  • /com.thoughtworks.xstream: just to keep the old stuff available at a location, where Maven can find it
  • /com/thoughtworks/xstream: for any 1.2.x release
  • /org.codehaus/xstream: for any 2.x release

Ben Walding - 19/Sep/06 06:10 AM
I've not forgotten this, I will hack you up a solution tomorrow afternoon.

Joerg Schaible - 19/Sep/06 11:46 AM
Thanks for the update. And I understand very well, that this is not your daily job ... same boat. Take your time and you might have a talk to Brett about the solution, since every Codehaus project might come into this situation. Better get it right than fast especially if you want to avoid abuse. And thanks for your efforts so far. Xircles is great.

Joerg Schaible - 27/Sep/06 03:37 PM
Ben, is there any update for this issue?

Ben Walding - 02/Oct/06 07:26 AM
I'm just going to watch what you do when you least expect it as I can't make head nor tail of how this relocation business works (I don't care enough I suspect ). This solution might change if a better solution is found.

http://dist.codehaus.org/xstream/ -> legacy id, same as before, upload artifacts as per normal
http://dist.codehaus.org/com.thoughtworks.xstream/ -> new m1 slot for the relocation stuff

you edit artifacts via the same old dav links => https://dav.codehaus.org/dist/xstream/

There's a directory in there called com.thoughtworks.xstream that is linked into the main dist site.

m2 => was already covered in previous changes


Joerg Schaible - 06/Oct/06 05:00 PM
Hi Ben,

thanks for your work. I had now the time to take a closer look. The only problem with the current solution is that xstream/com.thoughtworks.xstream will also be synchronized to the global Maven 1 repo

www.ibiblio.org/maven/com.thoughtworks.xstream
www.ibiblio.org/maven/xstream
www.ibiblio.org/maven/xstream/com.thoughtworks.xstream (?!?!)

... we'll see what the Maven folks say, when they synchronize ...


Ben Walding - 06/Oct/06 07:08 PM
You're right. I was trying to avoid having to give you a custom dav connection for it all.

Will do it up when I get a chance, probably in the next 48 hours due to a hectic weekend.


Joerg Schaible - 07/Oct/06 01:00 AM
Maybe you're better off in the long run, if you provide one DAV connection for each project only and give the project only write permission in the directory leaves. For XStream this could be something like

/site
/dist/xstream
/dist/com.thoughtworks.xstream
/m2/com/thoughtworks/xstream
/m2/org/codehaus/xstream

Any additional location (like /dist/com.thoughtworks.xstream or /m2/org/codehaus/xstream) must be requested by a haus chord.


Joerg Schaible - 14/Nov/06 11:19 AM
To correct some of my comments and to sum up all the necessary directories (at least for XStream):

/site: the web site
/dist/xstream: the location of the M1 artifacts with the old groupId of XStream 1.x
/dist/com.thoughtworks.xstream: the location of the M1 artifacts with the new groupId of XStream 1.x
/m2/xstream: the location of the M2 relocation POMs with the old groupId of XStream 1.x
/m2/com/thoughtworks/xstream: the location of the M2 artifacts with the new groupId of XStream 1.x
/m2/org/codehaus/xstream: the location of the M2 artifacts of XStream 2.x