You need to create a relocation POM for the release that does relocation to avoid hundred users to ask for upload on ibilio. The relocation POM will produce a warning on console for maven users. You can expect users to consider warnings and update groupId.
The relocation POM will not be required for N+1 releases. You MAY publish one if you consider not all users had time to update. This is similar to @deprecation warning in code : you can keep old code for some time but users are warned that it will be removed. 2007/2/13, Henri Yandell <[EMAIL PROTECTED]>:
On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Hi Hen, > > Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM: > > > Second try - having had it explained to me on #maven why relocating is > > important [so commons-lang:commons-lang 2.1 and > > org.apache.commons:commons-lang 3.0 are considered the same and a > > transitive clash can be recognized]. > > > > So, second suggestion: > > > > We declare a point after which we won't do any more m1 releases. We'll > > move wholesale over to m2. On that day (or as near as we can), we run > > a script on all commons-*/ to do the relocation for all of them ( > > http://maven.apache.org/guides/mini/guide-relocation.html ). > > > > I know I'm clueless - so please change this to whatever the clueful > > one is. I think it's time for us to drop m1 and move to m2. > > you cannot change the old POMs anymore, in that case this description is obsolete. The only > valid option is to use the new groupId with a new release and provide for this new release a > relocation POM at the former location. This was Carlos' advice after a two week hassle to do > such a transition with XStream. So we're cursed with having to do relocation poms every time we do a release? Is that something we can put in the parent pom? Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
