Gregory Kick wrote:
> On Aug 14, 2006, at 11:36 am, Kohsuke Kawaguchi wrote:
>
>> Gregory Kick wrote:
>>> Maven2 (and not Maven 1) has a mechanism for artifact
>>> relocation. Specifically, the relocation tag ( http://
>>> maven.apache.org/ref/ current/maven-model/
>>> maven.html#class_relocation ) in <distributionManagement>
>>> handles all of the appropriate information.
>>
>> Hmm, so the idea is that going forward, every time when we push a
>> new version, we put the POMs in the old names so that they point
>> back to the proper location?
>
> No, relocation is only necessary if the groupId or artifactId changes
> (rarely) or if the versioning __scheme__ changes (like java 1.5 ->
> java 5.0) (even more rare).
OK. If it's just one time work then that's much easier to do.
> Right, they work, but if you consider a maven repository as more than
> just a good way to string together dependencies ( http://
> kickstyle.net/pebble/2006/08/07/1154941800000.html ) it's pretty
> easily seen that fragmenting a single project under multiple groupIds
> causes the project meta-data to suffer.
Yes.
>> It only becomes a problem when they update the POMs to rely on a
>> newer version, in which case the simple solution is also to update
>> the groupId as well as version. That doesn't sounds like too much
>> effort to me.
>
> Honestly, it's not. But IMHO it's just as little effort to conform
> to best practices.
Yeah, the part that I was missing is that this is one time work, as
opposed to the on-going exercise.
>>> So, I definitely wouldn't say that using the javax.xml.bind
>>> groupId is wrong, but changing it without regard for the efforts
>>> of the users that promoted the project by putting it into ibiblio
>>> in the first place isn't exactly proper either.
>>
>> OK. But we've already published a fair number of versions on
>> javax.xml.bind and com.sun.xml.bind, so it doesn't seem like it's
>> possible to kill the new names either.
>>
>> Hence the suggestion to use the relocation tag?
>
> Right. My personal vote is to go with javax.xml.bind and just use
> the relocation POMs. The reason I didn't write them up as soon as I
> wrote the last email is that I had nothing to relocate 2.0EA3 to.
> And since uploading that will tie into the POM updates that I sent,
> (whatever happened to those..? they never got committed) I wasn't
> anxious to put another release out there with the old POMs.
Sorry, I must have dropped the ball somewhere along the line. Could you
open an issue and attach POMs there? That way I won't have to rely on my
short-term memory.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com