Yes, the main reason is that we experience problems with random SVN
connection failures when uploading new Metro artifacts via the usual
mvn deploy, which means that the whole build fails and the repository
is left in an inconsistent state. The same issue was experienced by
Jersey team and they are using the following workaround:
- checkout jersey root directory from the java.net maven2
repository SVN
- point the Jersey build to deploy locally to this checked out
repository
- commit the SVN changes
This fixes the connection problems and ensures that the whole
deployment is a single atomic operation. We wanted to follow this
approach, however given the fact that we had multiple groupIds to do
that we can either:
a) checkout the whole java.net maven 2 repository, which would be
obviously impractical
b) consolidate the metro artifact groupIds, to be able to checkout
just a small part of the maven repository
Consolidating Metro artifacts under the same root groupId is a good
thing in general IMHO and since we also had a much more pressing
reason, we decided to go that way.
Thanks,
Marek
On 26.10.2010, at 21:49, Jane Young wrote:
> Is there a reason why the groupId is changed from "javax.xml" to
> "org.glassfish.metro" for webservices-* artifacts?
>
>
> On 10/25/10 9:00 AM, Marek Potociar wrote:
>> Hi,
>> please find the Metro 2.1-b17 integration related changes here:
>> https://fisheye4.atlassian.com/changelog/glassfish-svn/trunk/v3?cs=42073
>>
>> Thanks,
>> Marek
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>