You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2010/09/13 19:06:22 UTC
Container integration systests and org.jvnet.jax-ws-common dependency
Hi,
on Friday I committed a change to cxf/trunk/systests/pom.xml for
including the container-integration systests in the build, as they were
(and still are) passing for me.
Today I see they build failed on hudson
https://hudson.apache.org/hudson/view/CXF/job/CXF-trunk-deploy/389/console,
basically because the
org.jvnet.jax-ws-commons:jaxws-grizzly-httpspi:jar:1.1 dependency is not
found on the central repo (well, it's actually grizzly too), while I got
the same locally from the http://download.java.net/maven/2/ repo which
is also used here.
What policy do we have for situations like this, if any ? Can I just add
the java.net repo, or should we try to find out if we can have those
artifacts pushed to central?
It would be really nice to keep those tests enabled..
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: Container integration systests and org.jvnet.jax-ws-common dependency
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Alessio
On Mon, Sep 13, 2010 at 6:06 PM, Alessio Soldano <as...@redhat.com>wrote:
> Hi,
> on Friday I committed a change to cxf/trunk/systests/pom.xml for including
> the container-integration systests in the build, as they were (and still
> are) passing for me.
> Today I see they build failed on hudson
> https://hudson.apache.org/hudson/view/CXF/job/CXF-trunk-deploy/389/console,
> basically because the org.jvnet.jax-ws-commons:jaxws-grizzly-httpspi:jar:1.1
> dependency is not found on the central repo (well, it's actually grizzly
> too), while I got the same locally from the
> http://download.java.net/maven/2/ repo which is also used here.
> What policy do we have for situations like this, if any ? Can I just add
> the java.net repo, or should we try to find out if we can have those
> artifacts pushed to central?
>
I believe there were some issues with the java.net repo before, but given
that it is only the container-integration systests which are affected, I'd
just add this repo to the container-integration/pom.xml - unless there's
indeed a global no-java.net policy in place
cheers, Sergey
It would be really nice to keep those tests enabled..
> Cheers
> Alessio
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
Re: Container integration systests and org.jvnet.jax-ws-common dependency
Posted by Alessio Soldano <as...@redhat.com>.
Hi Dan,
OK, thanks. For now I've added that just to the
systests/container-integration/grizzly; I'll try to get in touch with
someone at Sun/Oracle to push the artifacts to central.
Cheers
Alessio
On 09/14/2010 09:43 PM, Daniel Kulp wrote:
> Bascially, I have "less" problems with using java.net repos for test scope
> things and in the modules only used for the tests. (systest/*) What I DON'T
> want to see is any java.net requirements ending up in normal runtime scopes of
> things end users might hit. (and I'd prefer no java.net things anywhere)
>
> Basically, java.net has broken us in MULTPLE occasions in the past (saaj-impl
> twice, jaxws-api once, jaxb once, I think a couple other times as well) by re-
> relasing artifacts and such without updating version numbers and things.
> Admittedly, that was with the m1 repo and not the m2 repo, but I really don't
> trust them at all. Plus, adding repos to the build slows down the builds as
> well as requires users to configure additional things in the settings.xml or
> Nexus instances and such which kind of sucks. Thus, if it's at all avoidable,
> it's best to avoid additional repos.
>
> In general, the BEST thing to do is email the projects and ask them to work
> with Sonatype to get their artifacts to Central instead of any of the other
> repos. That helps everyone.
>
>
> Dan
>
>
>
>
> On Monday 13 September 2010 1:06:22 pm Alessio Soldano wrote:
>> Hi,
>> on Friday I committed a change to cxf/trunk/systests/pom.xml for
>> including the container-integration systests in the build, as they were
>> (and still are) passing for me.
>> Today I see they build failed on hudson
>> https://hudson.apache.org/hudson/view/CXF/job/CXF-trunk-deploy/389/console,
>> basically because the
>> org.jvnet.jax-ws-commons:jaxws-grizzly-httpspi:jar:1.1 dependency is not
>> found on the central repo (well, it's actually grizzly too), while I got
>> the same locally from the http://download.java.net/maven/2/ repo which
>> is also used here.
>> What policy do we have for situations like this, if any ? Can I just add
>> the java.net repo, or should we try to find out if we can have those
>> artifacts pushed to central?
>> It would be really nice to keep those tests enabled..
>> Cheers
>> Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: Container integration systests and org.jvnet.jax-ws-common dependency
Posted by Daniel Kulp <dk...@apache.org>.
Bascially, I have "less" problems with using java.net repos for test scope
things and in the modules only used for the tests. (systest/*) What I DON'T
want to see is any java.net requirements ending up in normal runtime scopes of
things end users might hit. (and I'd prefer no java.net things anywhere)
Basically, java.net has broken us in MULTPLE occasions in the past (saaj-impl
twice, jaxws-api once, jaxb once, I think a couple other times as well) by re-
relasing artifacts and such without updating version numbers and things.
Admittedly, that was with the m1 repo and not the m2 repo, but I really don't
trust them at all. Plus, adding repos to the build slows down the builds as
well as requires users to configure additional things in the settings.xml or
Nexus instances and such which kind of sucks. Thus, if it's at all avoidable,
it's best to avoid additional repos.
In general, the BEST thing to do is email the projects and ask them to work
with Sonatype to get their artifacts to Central instead of any of the other
repos. That helps everyone.
Dan
On Monday 13 September 2010 1:06:22 pm Alessio Soldano wrote:
> Hi,
> on Friday I committed a change to cxf/trunk/systests/pom.xml for
> including the container-integration systests in the build, as they were
> (and still are) passing for me.
> Today I see they build failed on hudson
> https://hudson.apache.org/hudson/view/CXF/job/CXF-trunk-deploy/389/console,
> basically because the
> org.jvnet.jax-ws-commons:jaxws-grizzly-httpspi:jar:1.1 dependency is not
> found on the central repo (well, it's actually grizzly too), while I got
> the same locally from the http://download.java.net/maven/2/ repo which
> is also used here.
> What policy do we have for situations like this, if any ? Can I just add
> the java.net repo, or should we try to find out if we can have those
> artifacts pushed to central?
> It would be really nice to keep those tests enabled..
> Cheers
> Alessio
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog