cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: Container integration systests and org.jvnet.jax-ws-common dependency
Date Wed, 15 Sep 2010 07:36:30 GMT
  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


Mime
View raw message