This is something I've mentioned in passing, but I'll reiterate it
here because i think it's particularly applicable.
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.
The reason that I mention it now is that groupIds are not an exact
science and it doesn't really matter what you pick. All they are are
unique identifiers and although they have guidelines to facilitate
usability, nothing really dictates what they are. However, it's
obvious that some choices are better than others and because the best
choice might not be immediately apparent, they may change. It is in
these cases that relocation becomes vital. All versions of all
artifacts need to have the the current, accurate groupId regardless
of what they were released under and the pom for relocation
facilitates those changes without disrupting the user.
This is all complicated by the fact that it is all being published in
ibiblio. There is an expectation that the information contained
within is accurate and reliable because it's the "main repository".
So, if a change is to be made, there is an expectation that it be
handled in the proper way. However, the information in there comes
from two sources: other repositories that are synchronized and
information pushed in from users. Other repositories, like maven-
repository.dev.java.net, typically contain authoritative information,
but anyone can push information as well. There's some checking done
and a bit of discussion, but in the end, a lot of misinformation can
find its way in.
This puts project owners in a bit of an awkward position. Not only
do they have the responsibility of supplying ibiblio with correct
information, but they also have to look after the information about
their projects inputted by others. In this case, as developers for
jaxb, Kohsuke and the rest get to pick whichever groupIds they want
because that is their prerogative, but as members of the maven
community there's a certain amount of responsibility to supply
correct information for the previous entries as well. 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.
So, that's my bit of preaching. :-)
On Aug 11, 2006, at 11:11 am, Kohsuke Kawaguchi wrote:
> Franz Fehringer wrote:
>> Hello,
>> Are there any current activities for enabling JAXB2 support in
>> Maven2?
>> In http://www.ibiblio.org/maven2/javax/xml/ there are jaxb-api
>> jaxb-impl jaxb-xjc, but they still contain only 2.0EA3.
>> Since 17. of july there is an additional subdirectory bind, but
>> there are several things wrong/missing with this:
>
> We arranged a mirroring from java.net repo to the maven repo, so
> that's why we started seeing jars in ibiblio.
>
>> * jaxb-impl and jaxb-xjc are missing.
>
> They are there: http://www.ibiblio.org/maven2/com/sun/xml/bind/
>
>> * version is 2.0; 2.0.1 and 2.0.2 have appeared in the meantime.
>
> Yeah, I have to ask them why those new jars are not mirrored.
>
>> * it has been mentioned on this list, that the location
>> javax/xml/bind is wrong, javax/xml is the correct one.
>
> I really think it should be javax/xml/bind. There's no single group
> that is in charge of "javax.xml" packge at JCP. It's individual
> JSRs that own individual packages like "javax.xml.bind" and
> "javax.xml.ws". They follow different development models, release
> cycles, etc. So the group name should better reflect that structure.
>
> We kept JAX-RPC API in "javax.xml" to honor the backward
> compatibility, but for new jars, I'm not sure why we need to
> continue that way. I thought the Maven folks are in agreement with
> this, as you can see in http://www.ibiblio.org/maven2/javax/xml/bind/
>
> The same can be said with "com.sun.xml", and I can make even
> stronger case here. Sun clearly owns this namespace, and so I
> thought the group in Sun that does "com.sun.xml" stuff gets to
> choose whatever conventions we see fit. Again, it's the same deal
> with javax.xml here --- there are individual groups that work on
> "com.sun.xml.bind" and "com.sun.xml.registry" and so on, and so it
> made more sense to us for each team to own its groupId.
>
> There's also no backward compatibility issue in "com.sun.xml.*", as
> this is the first time we publish any artifacts into these group
> Ids, unlike "javax.xml". So I don't understand why people are
> objecting to "com.sun.xml.bind" group id. What is the problem of
> this group id?
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
greg kick
http://kickstyle.net/