Christopher wrote:
FWIW, it was reported to metoday that a user ran into an issue where my
recent update of commons-configuration caused an integration problem
because our scripts/packaging do not bundle commons-configuration and we
just assume it will work with the version provided by Hadoop lib directory.
That's the kind of thing I'd like to avoid... users should understand that
assumptions in our packaging may not work for them, and we're creating work
for ourselves while failing to communicate that when we try to bundle
everything for them.
If we were a self-contained application, we could even go the opposite way,
and bundle everything. But, we're not. We're picking and choosing what to
bundle, and our choices might not be right. We should make it easier for
the users to choose, instead.
Perhaps tangential (but maybe not?): I would love to get to a point
where we prevent the ability for users to be depending on Accumulo for
dependencies. While there are security reasons that we would want to
really sandbox iterators entirely, it would be good to encourage a model
of iterator deployment which doesn't push users to developing a
dependence on the JARs that we bundle.
IMO, the jars we bundle should only be used by us. Users shouldn't know
about them and they should include the necessary things they require.
