accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 15:37:04 GMT
On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey <> wrote:

> Targeting for 2.0, including updates in the README, and having mean for
> helping
>  the downstream user find the appropriate licensing information makes me
> much
> more comfortable with this.
> I have to ask though, why not just do source only releases? Or source

Not having the binary release would suck.  Its nice to be able to easily
test the latest version of Accumulo on a cluster.  Would not be able to
easily run our own cluster test suites against release candidates.

> + publishing
> the binary jars to maven central needed for the public API?
> On Thu, Jun 30, 2016 at 8:03 PM, Christopher <> wrote:
> >
> > 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.
> >
> This reasoning seems like avoiding the real problem, which seems distinct
> from
> not bundling 3rd party works. It's our job as a community to keep
> accurate track of
> our dependency licensing, even if we don't need to make a document about
> it,
> because we have to ensure that cat-x is kept out*.
> Changes needed in our LICENSE/NOTICE for a bundled dependency change
> should be getting handled by whomever does each dependency change. Folks
> who review changes (even in our commit-then-review process) should be
> pointing
> out where due diligence hasn't been done. We spent a ton of time getting
> our
> LICENSE/NOTICE files correct back in September. It'd be super
> disappointing if
> that impact of that effort atrophied.
> > 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.
> If the downstream users are going to be fulfilling dependencies themselves,
> should we try to provide an accurate range of versions that we properly
> work
> with?
> * barring maneuvers related to "optional" deployment dependencies, natch.
> --
> busbey

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