On Mon, Jul 18, 2016 at 2:24 PM Josh Elser <josh.el...@gmail.com> wrote:
> Christopher wrote: > > On Thu, Jun 30, 2016 at 5:43 PM Christopher<ctubb...@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. :(
