Forwarding a message from Carlos, as it was rejected by the member check
of the mailing list.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
attached mail follows:
To avoid spams, this list is configured to require a subscription
before posting a message. Please follow the instructions below:
1. To subscribe to the list, send a blank message to:
users-subscribe_at_jaxb.dev.java.net
Or, if you prefer digest subscriptions, send a blank message to:
users-digest-subscribe_at_jaxb.dev.java.net
2. You will receive a confirmation message for you subscription
request in a few minutes. Please confirm your subscription by
replying to the message.
3. Please resubmit your message.
If you are using multiple e-mail addresses, please make sure that
you post messages from the exact same e-mail account that you
subscribed to the list. Otherwise your message will be rejected.
The 'Original-Recipient' header of e-mails delivered from this list
shows the e-mail address under which you are subscribed.
Here is some additional information you may find useful:
- To unsubscribe from this mailing list, write an empty e-mail to:
users-unsubscribe_at_jaxb.dev.java.net
- The entire archive is available at:
https://jaxb.dev.java.net/servlets/SummarizeList?listName=users
- You can search the archive at:
https://jaxb.dev.java.net/servlets/SearchList?listName=users&by=date
- If you have java.net account, all those operations are available
through the web interface. Go to
https://www.dev.java.net/servlets/Join
to create an account, and then go to
https://jaxb.dev.java.net/servlets/ProjectMailingListList
- For more list commands, send a blank e-mail to
users-help_at_jaxb.dev.java.net
- The list is run by ezmlm.
If you continue to experience posting problems, please
contact the project owner at "owner at jaxb dot dev dot java dot net"
attached mail follows:
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 <Kohsuke.Kawaguchi_at_sun.com> 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
>
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride