Kohsuke is right, although old stuff may be under javax.xml and
com.sun.xml we see better fit under javax.xml.something and as they
manage com.sun.* they can do however they want there (and we are not
involved in this later case).
On 8/11/06, Kohsuke Kawaguchi <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
