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 Re: hbase-specific maven dependencies
Date Thu, 27 Sep 2012 20:41:54 GMT
On Thu, Sep 27, 2012 at 12:24 PM, Gary Helmling <ghelmling@gmail.com> wrote:

> 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
My concern is that while in this case it was a temporary thing, its
something that we do with some frequency. And the fact that we have two
different repositories already (yours and stacks). It would be better to
consolidate and put it under source control.

> 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
I'm fine with the source being somewhere else, as long as the pom for that
artifact has that information in it, so interested parties can know where
to look.

When we do host special artifacts, we should also put up a -source tarball
too so IDEs can pull down those sources automatically.

> >
> >    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.

All a maven repo is is just a remotely accessible directory with a certain
structure - nothing fancy.

> >    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?

I'd assume its globally owned by comitters and they have the credentials.
But then we already have that with svn....

>  Is there any ASF
> resource that we can use here instead?

No idea.

> 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.

A single unified location and ability to see easily version changes,
updates, etc would be a start. Cleaning up the pom is another.

> Are there
> build changes we'd like to make that this is blocking?

Not that I know of. It just seemed like a nice cleanup.

> 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.

That's a start, but I don't think solves all our problems. Also, I heard
from LarsH that apache was planning on taking away those directories?

> 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.


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