Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAF1jEfAab=BH_zAR68_w+mS9UP6UMrpi94-u0SaOSQ4eq4p0jA@mail.gmail.com>
References: 
 <CAL5zq9Yg4MXA0ktF1pW9dQvG+So4v=7VN7btbPvfy+XEypADkA@mail.gmail.com>
	<CAF1jEfAab=BH_zAR68_w+mS9UP6UMrpi94-u0SaOSQ4eq4p0jA@mail.gmail.com>
Date: Mon, 6 May 2013 19:00:56 -0400
Message-ID: 
 <CAL5zq9Y_bLWUGfaN__oUbtsPe37bCFMNwP3NO3BFTQpjoFhMkQ@mail.gmail.com>
Subject: Re: Drop version part of jar filenames in $ACCUMULO_HOME/lib
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

I never unpack over top of an existing installation, but that's not
the only advantage. For instance, not having to update scripts is
nice.

Adding a VERSION file is reasonable... but it'd just be a convenience
if one doesn't do the symlinking thing that Billie mentioned, where
one can see the top level directory name.

I see 3 main cases for deploying Accumulo:
1) Using RPM/DEB, which manages versions of files for you, and the
version in the filename is irrelevant.
2) Unpacking a tarball into a separate directory, with a name
according to the version, in which case the version in the filename is
irrelevant.
3) Unpacking a tarball into the same directory, overwriting, in which
case the filename without a version is actually very convenient.

Regarding mixing versions of jars:

There's the case that somebody could copy into a directory a jar from
another version... but that's essentially the same problem as somebody
accidentally renaming a jar, and we can't protect against that. In the
worst case scenario, one simply needs to inspect the
META-INF/MANIFEST.MF file from the jar to know for sure what version
it is.

Regarding easily telling which version one is using:

A VERSION file is convenient, and so is a directory name. RPM/DEB
handle this for you.

Keep in mind that this entire discussion is about what goes into the
binary distribution tarball's lib directory, though. Jars downloaded
from Maven will still have the version numbers in their filename, and
all jars will still have a MANIFEST.MF file with the version in it.
Looking at other packaging (outside of the Hadoop eco-system),
stripping the version from the name seems to be a quite common
practice.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, May 6, 2013 at 6:42 PM, Billie Rinaldi <billie.rinaldi@gmail.com> wrote:
> On Mon, May 6, 2013 at 2:26 PM, Christopher <ctubbsii@apache.org> wrote:
>
>> Why do we need the version part of the filename in $ACCUMULO_HOME/lib?
>>
>> It seems to me that it would be cleaner to unpack the tarball on top
>> of an existing $ACCUMULO_HOME/ and overwrite the jars in lib/.
>>
>
> Do we want to encourage unpacking the tarball on top of an existing
> installation?  This seems like something that could be error-prone.  I
> prefer keeping separate directories for each installation and symlinking
> the one I want to use to my standard ACCUMULO_HOME.
>
> Billie
>
>
>
>>
>> For the RPM/DEB, the versions of the files are tracked in the RPMDB
>> (or equivalent DEB database), so they aren't needed there either.
>>
>> It would make our scripts slightly more manageable (files have a
>> predictable name that doesn't need to be updated each version).
>>
>> I'm curious what the argument(s) against dropping the version from the
>> jars in lib/ are.
>>
>> The way we copy jars currently to lib/ is with the
>> maven-dependency-plugin, and that already has a built-in feature to
>> drop the version part of the filename when it copies. It seems to make
>> sense, and I see no argument against it.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>