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 <[email protected]> wrote: > On Mon, May 6, 2013 at 2:26 PM, Christopher <[email protected]> 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 >>
