accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4356) Stop bundling dependencies in binary tarball
Date Thu, 30 Jun 2016 21:50:10 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357915#comment-15357915
] 

Christopher Tubbs commented on ACCUMULO-4356:
---------------------------------------------

Yes, certainly it's slightly less convenient... but many such users already have to do their
own dependency convergence to use Accumulo with their preferred distribution of Hadoop, and
our upstream assumptions aren't always valid anyway for those users. (FWIW, I'm speaking as
a representative of an organization to which this case applies. We also build from source,
so the binary distribution isn't that useful to us generally, but that's not to say it's not
useful to others.)

> Stop bundling dependencies in binary tarball
> --------------------------------------------
>
>                 Key: ACCUMULO-4356
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4356
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: build
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>              Labels: newbie
>             Fix For: 2.0.0
>
>
> Currently, our binary tarball is built containing our own built jars, scripts, etc. as
well as some extra dependencies which we assume are not available in either the Hadoop lib
directory or the ZooKeeper lib directory.
> These assumptions are tenuous, since we do not know what environment a user is going
to be running in, and which jars they already have installed on their system, provided by
their classpath or otherwise. Nor do we know whether the specific versions of the dependencies
we're bundling for the user are compatible with what they have on their system.
> What we are trying to do is make things convenient for a user, by performing integration/packager/dependency
convergence tasks on behalf of the user... all based on poorly defined assumptions.
> This bundling also adds an extra burden on us, as the upstream project, to maintain complex
LICENSE/NOTICE files for the bundled tarball artifact we produce, and it's *very* easy for
these legal files to unintentionally become out of sync when we change a version of a dependency
we are bundling.
> We should not bundle any dependencies inside our binary tarball. For convenience, we
can instead provide a script which allows the user to easily download the dependencies we're
currently assuming they will need (the same ones we're currently packaging for them). This
will provide nearly the same convenience as we are currently providing, but in a way which
does not require burdensome maintenance on our LICENSE/NOTICE files, and in a way that the
user could easily customize this script to download the dependencies they actually need, if
our assumptions aren't valid for their environment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message