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 dk...@apache.org http://dankulp.com/blog
