accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Mon, 18 Jul 2016 18:24:40 GMT
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.

Mime
View raw message