Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
References: <CAL5zq9ZYAPsaLWw2+BpT6SZmE-5CgcXrHjBdQxohRy0UtscQkA@mail.gmail.com>
 <CAL5zq9aJFykUsvaEx13C9qGqjeGNYL+trH6t5PSdXRBN3oAP_A@mail.gmail.com> <578D1EE8.9030705@gmail.com>
In-Reply-To: <578D1EE8.9030705@gmail.com>
From: Christopher <ctubbsii@apache.org>
Date: Mon, 18 Jul 2016 20:27:46 +0000
Message-ID: <CAL5zq9bRd7vuMegMdByWQ+XFrKDqsraW=u-vTdFKEqXEfPrSng@mail.gmail.com>
Subject: Re: [DISCUSS] Proposed binary packaging changes
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=94eb2c063a18affd430537eecdaf
archived-at: Mon, 18 Jul 2016 20:27:59 -0000

--94eb2c063a18affd430537eecdaf
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 18, 2016 at 2:24 PM Josh Elser <josh.elser@gmail.com> wrote:

> Christopher wrote:
> > On Thu, Jun 30, 2016 at 5:43 PM Christopher<ctubbsii@apache.org>  wrote:
> >
> >> Hi all,
> >>
> >> I'd like to bring to your attention
> >> https://issues.apache.org/jira/browse/ACCUMULO-4356, for discussion.
> Feel
> >> free to comment here or on the issue.
> >>
> >
> > Reading back through all the replies, I don't see a *strong* consensus,
> but
> > it does seem like there's some acceptance of my proposal (perhaps with
> some
> > reservations).
> >
> > It seems people are mostly "okay" with this, so long as it's pushed off
> to
> > the future (2.0+), and is accompanied by some automated way of
> downloading
> > dependency jars, and collating their LICENSE/NOTICE files.
> >
> > So, unless there's more discussion here, my intention is to proceed to
> > create a pull request against the 2.0 branch (currently: master) which
> > replaces our assembly bundling with a downloader script. That way, if
> > there's any additional feedback on the specific implementation, folks
> will
> > be able to comment directly on that.
> >
>
> I've had quite the foray into ASF release policies over the past two
> days which brings me back to this.
>
> I really don't believe that the amount of effort you claim we will save
> will actually be beneficial overall. Our dependencies do not frequently
> change which means that our L&N also do not frequently change.
>
> Even if I do concede that it will make things more simple for Accumulo
> in the short-term, you're forcing change from N organizations which
> already integrate Accumulo in its current state (you would force all
> downstream to change). I would rather solve this once in Accumulo.
>
> If you want to create such a script to help users build their own
> artifact for their specific installation: great. I believe that the
> argument that such a script would save time in Accumulo in managing our
> L&N is false.
>

I know it would have saved me a ton of time (and sanity) moving to
commons-math3. How often it saves us time is debatable, agreed. But, that's
not a primary motivation. It's just a slight benefit, which might reduce
the burden of bumping dep versions.

I have a PR ready to push... not sure I'm 100% happy with it, because of
the way it downloads deps one at a time (might be easier to download then
all at once using maven... but with some complication), and some of the
changes need to be pushed as a separate commit anyway. So perhaps you'll be
able to see better what I'm thinking when you can see the changeset.

As I said before, this isn't really about a single (or a few) big
benefit(s). It's about numerous tiny ones, which are admittedly hard to
measure. Whether it pays off in the long-run is hard to tell, but that's
what I'm targeting... the long-term, though there may be some road bumps in
the short-term. I'm convinced this is the right thing to do, but I can
understand the reluctance to accept my conclusion, when I've not done a
good job of articulating dramatic, easy-to-see benefits. :(

--94eb2c063a18affd430537eecdaf--