hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n keywal <nkey...@gmail.com>
Subject Re: hbase-specific maven dependencies
Date Fri, 28 Sep 2012 20:04:35 GMT
I totally agree with Gary.

We can industrialize the way we manage internally a custom dependency, but
the most important part is being able to come back to the official release,
and this part can't be industrialized as it does not depend on us...


On Fri, Sep 28, 2012 at 8:11 PM, Gary Helmling <ghelmling@gmail.com> wrote:

> > 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.
> >
> I'm sure others would say the fact that we do this with some frequency
> is the problem, that the custom built dependencies are the real issue.
>  And moving them from one repo to another doesn't solve that.
> If this is going to be an ongoing need for the future, with new custom
> built dependencies coming up then I can see the benefit of a shared
> resource.  But personally I hope that we can actually remove the need
> for my repo much sooner than later.  And forking our own patched
> builds doesn't really fit so well with the Apache way, which I think
> would prefer that we work the the other communities to get the changes
> we need released.  (Yes, I'm arguing this even though I'm hosting our
> current patched builds, because I think it's best if we avoid going
> this route in the future.)
> >>
> >> 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.
> >
> >
> Until we have new needs for custom builds, which we should look at on
> a case-by-case basis anyway, I don't really see this applying.  Until
> then it seems like duplicating work that's already gone in to
> producing and deploying the existing builds.
> >>
> >> 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?
> >
> As I understand it, these were entirely separate committer repos being
> removed, unrelated to our (ab)use of public HTML access on
> people.apache.org.
> If you see enough benefit here to invest the effort then you are of
> course welcome to do so.  I'd be happy to see use of my repo removed.
> But if all we're doing is moving our existing custom builds from one
> place to another, then that just seems like a duplication of effort
> that's already been sunk, without getting us closer to the end outcome
> of eliminating the custom builds and using actual releases.  But
> everyone on this project is free to invest effort where they see fit.
> --gh

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