If we do this, then we should add a version file of some variety to make it
easy to determine.
On Mon, May 6, 2013 at 5:59 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> Also, it make things more difficult to determine version-mismatch across a
> system if someone is not using the RPMs/DEBs. Perhaps pidgeon-hole'ing
> non-RHEL/Debian based (GNU/)linux's?
> On 5/6/2013 5:57 PM, Josh Elser wrote:
>> Personally, it's really nice to me when I'm wondering "what version of
>> Accumulo is installed?" and I can easily answer that with an `ls`.
>> However, by the same argument, bundling a version file somewhere is just
>> as trivial and fits the same use-case (sans my ability to remember that
>> said file exists and where it lives).
>> On 5/6/2013 5:26 PM, Christopher 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/.
>>> 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