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]
smime.p7s
Description: S/MIME Cryptographic Signature
