accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 01:03:10 GMT
On Thu, Jun 30, 2016 at 8:13 PM Dylan Hutchison <dhutchis@cs.washington.edu>
wrote:

> Thanks for highlighting Chris. Some thoughts:
>
> There are steps defined in the README and INSTALL for setting up Accumulo
> from the binary distribution. It sounds reasonable to add additional steps
> for downloading dependencies into the lib/ folder to these documents, as
> long as the instructions are clearly explained. Bonus points for including
> a helper script.
>
>
Yep. README will be key.


> Organizations that manage dependencies in an offline environment will still
> have guidance for what artifacts and which versions to obtain and where to
> put them.
>
> I suggest delaying the change to 2.0.0, since some users would be surprised
> by the switch.
>
>
Agreed. I preemptively labeled the issue for 2.0.0, because I figured
traction any sooner would be impossible. :)


> We should also remember the aphorism "if it ain't broke, don't fix it." Are
> users running into compatibility problems with the classpath or class
> loaders? If yes, then this is important. If not, it could still be a good
> thing, and I would support it if someone is energized to implement the
> change. It sounds like this would make the release process and future
> maintenance easier, especially on the legal end.
>
>
The impetus for this was that I recently bumped our commons-math dependency
to commons-math3, and it was such a time sink to try to track down even
just that one bundled dependencies LICENSE/NOTICE modifications. I
seriously doubt our LICENSE/NOTICE files are fully up-to-date and in sync
with other bundled deps which have been updated over time.

But, to the question of whether it's broke... I've seen several cases where
a version in our lib directory caused a problem with a version of the same
classes elsewhere in the user's system. The user thought they could just
avoid any dependency convergence/reconciliation on their part, because they
thought Accumulo would just work... and when it didn't, they blamed
Accumulo when it was their specific environment which was the problem. If
we communicate that responsibility up front, perhaps we wouldn't get blamed
when users fail to do their due diligence to converge their dependencies or
when they use wildcards excessively in their classpath configs.


> Projects like accumulo-quickstart(1) are critical for allowing users to
> play around with Accumulo at low entry barrier. Let's make sure that (or a
> similar) project still works.
>
>
Agreed.


> (1) https://github.com/accumulobook/quickinstall
> (Pending PR) https://github.com/accumulobook/quickinstall/pull/1
> On Jun 30, 2016 3: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.
> >
>

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