hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject hbase-specific maven dependencies
Date Thu, 27 Sep 2012 18:00:28 GMT
Hey all,

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:
      <name>Gary Helmling test repo</name>

(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*).

This leads to a lack of visibility and flexiblity into the objects being
deployed - we are dependent on the committer to put up the right version
and their benevolence when we want to change the artifact, all with without
any history of what they were doing (not saying we don't trust you fellas).

I'd like to propose that we start storing these built artifacts either:

   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
   2. In one of the free sonatype respositories that we can name
   hbase-custom-dependencies (or some such).

The former has the advantage that we have full control over the repository
as well as commit history on that branch to audit changes.
The latter is nice in that it's an official repo (they are supposedly free
for OSS projects), but we loose a bit of the visibility into changes and
its a lot more friction to setup.

Personally I'm predisposed to (1), especially because they are just
hbase-specific dependencies. Any projects depending on hbase via maven will
automatically pull in the right dependencies, without the micro-repository



Jesse Yates

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message