> I was poking around the pom yesterday and noticed that we are hosting our > own special artifacts (e.g. our custom surefire plugin via Keywal's) in > various commiters' apache 'mvn' repositories. For instance, the surefire > plugin is hosted here: > * > <repository> > <id>ghelmling.testing</id> > <name>Gary Helmling test repo</name> > <url>http://people.apache.org/~garyh/mvn/</url> > <snapshots> > <enabled>true</enabled> > </snapshots> > <releases> > <enabled>true</enabled> > </releases> > </repository> > * > > (And so I'm not just picking on Gary, Stack has one too :) for hosting > asynchbase, which is another discussion as to whether or not we should be > doing *that*). >
See HBASE-4955. This was never seen as a permanent feature, but rather as a stop gap measure (though it's now been around for a while). Nicolas has been working hard to get these changes in upstream, but we're still blocked waiting on official releases. Once those are out, this repo is no longer necessary. There are 2 issues here: * the hosting of the build artifacts as dependencies * the hosting of sources used to build those artifacts The source code for the artifacts is available at: Junit: 4.10-HBASE-1, source code on https://github.com/nkeywal/junit, branch "hbase" Surefire: 2.12-TRUNK-HBASE-2, source code on https://github.com/nkeywal/maven-surefire > > 1. In a branch of hbase that is web-accessible and just reference that > branch as a maven repo > 1. I'm (perhaps foolishly) volunteering to setup the pom to make this > happen So making the ASF svn repo the maven repo instead? That seems like a weird hack to me, though I suppose it would at least be accessible to others. > 2. In one of the free sonatype respositories that we can name > hbase-custom-dependencies (or some such). > Who would own this and how would we control access? Is there any ASF resource that we can use here instead? If someone else wants to setup a new repo for hosting these they are welcome to, but personally I don't see much of a benefit. Are there build changes we'd like to make that this is blocking? If the problem is just accessibility to other committers, another hacky solution is that I just make my ~garyh/mvn directory writable by the hbase group so that other committers could make changes if necessary. But I think the best solution is to get the upstream releases out so that we can eliminate the custom dependency repos entirely. Unfortunately we don't have much control over that.
