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).
>
> But is the current situation that painful? I mean, it's not like we
> are erasing the old artifacts. So the POMs out there that rely on
> existing jars in the javax.xml would continue to work.
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.
>
> 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.
>
>
>> 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.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
greg kick
http://kickstyle.net/