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 >>> http://gravatar.com/ctubbsii >>> >> >> >
