Billie- Yes, the original intent was to make it look like a normal ACCUMULO_HOME directory. Unfortunately, the best, easiest way to do this is to use the assembly plugin, and it makes these extra directories. It can't be helped... at least, I didn't think it was worth wasting time on it, like I spent so much time doing getting the filenames right in 1.5.0 artifacts. I think it might be best to change the name of the parameter so it's not misleading, though.
David- Update. It won't do that anymore. It'll grab everything else that normally goes in the tarball, too. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Jun 6, 2013 at 12:56 PM, David Medinets <david.medin...@gmail.com> wrote: > It did not behave that way for me. Three directories were created bin, > conf, and lib. Directly where my DEV_ACCUMULO_HOME pointed to. > > > On Thu, Jun 6, 2013 at 11:47 AM, Billie Rinaldi > <billie.rina...@gmail.com>wrote: > >> I'm trying this out. Based on the name of the parameter >> (DEV_ACCUMULO_HOME) I was expecting it to look like a normal accumulo home >> directory, but it actually creates >> DEV_ACCUMULO_HOME/accumulo-1.6.0-SNAPSHOT-dev/accumulo-1.6.0-SNAPSHOT. I >> can see why you'd want a subdirectory with the version number, but why are >> there two subdirectories? >> >> Billie >> >> >> On Tue, Jun 4, 2013 at 9:38 AM, Christopher <ctubb...@apache.org> wrote: >> >> > Slight change. I take back what I said before: by default it does >> > create the assembled directory (what will go in the bin tarball) in >> > assemble/target. But, that is subject to being wiped out by 'mvn >> > clean'. Specifying the property with a different location, outside the >> > target directory will protect it from being "cleaned". >> > >> > Also, because it reuses the same component profile as the bin tarball, >> > it basically means that it will create an directory that should look >> > exactly like what the unpacked bin tarball would look like. >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Mon, Jun 3, 2013 at 4:37 PM, Christopher <ctubb...@apache.org> wrote: >> > > Oh, well, I should clarify... the things that would normally go *in* >> > > that directory (such as jars) would still end up in their respective >> > > target directories (except those things copied directly from the >> > > source tree, like the scripts and configuration). >> > > >> > > -- >> > > Christopher L Tubbs II >> > > http://gravatar.com/ctubbsii >> > > >> > > >> > > On Mon, Jun 3, 2013 at 4:36 PM, Christopher <ctubb...@apache.org> >> wrote: >> > >> Nope. If you don't set the property, then it won't copy files to that >> > >> directory, and you'll have to build the binary assembly or rpm or deb >> > >> and unpack/install that, as we expect end-users to normally do, in >> > >> order to get a similar structure. >> > >> >> > >> -- >> > >> Christopher L Tubbs II >> > >> http://gravatar.com/ctubbsii >> > >> >> > >> >> > >> On Mon, Jun 3, 2013 at 4:22 PM, David Lyle <dlyle65...@gmail.com> >> > wrote: >> > >>> What happens if I don't set the property? Does everything end up >> under >> > >>> target? >> > >>> >> > >>> >> > >>> On Mon, Jun 3, 2013 at 4:06 PM, Christopher <ctubb...@apache.org> >> > wrote: >> > >>> >> > >>>> Minor correction. The basic method for specifying the external >> > directory >> > >>>> is: >> > >>>> mvn -DDEV_ACCUMULO_HOME=<absolutePath> package >> > >>>> >> > >>>> -- >> > >>>> Christopher L Tubbs II >> > >>>> http://gravatar.com/ctubbsii >> > >>>> >> > >>>> >> > >>>> On Mon, Jun 3, 2013 at 4:04 PM, Christopher <ctubb...@apache.org> >> > wrote: >> > >>>> > I made some changes for ACCUMULO-935 that may be unexpected, so >> > here's >> > >>>> > some information that may help: >> > >>>> > >> > >>>> > Use 'mvn -DDEV_ACCUMULO_HOME package' to output built artifacts to >> > an >> > >>>> > external directory, so the workspace does not get dirtied with >> > >>>> > unversioned files outside of the target directories, that need to >> be >> > >>>> > constantly excluded with svn:ignore, .gitignore, rat-maven-plugin, >> > and >> > >>>> > exceptions. >> > >>>> > >> > >>>> > In this external directory, you should be able to run >> bin/accumulo, >> > >>>> > store your conf/* files, etc. Just as before, when you could set >> > >>>> > general.classpaths to include target/classes in each module, you >> can >> > >>>> > still do that, pointing to your svn/git checkout target/classes >> > areas. >> > >>>> > >> > >>>> > Put the following in settings.xml to always copy jars/output to a >> > >>>> > runnable ACCUMULO_HOME area, so you don't need to put it on the >> > >>>> > command line every time: >> > >>>> > >> > >>>> > <profiles> >> > >>>> > <profile> >> > >>>> > <id>inject-accumulo-home</id> >> > >>>> > <properties> >> > >>>> > >> > <DEV_ACCUMULO_HOME>/var/tmp/ACCUMULO_HOME</DEV_ACCUMULO_HOME> >> > >>>> > </properties> >> > >>>> > </profile> >> > >>>> > </profiles> >> > >>>> > <activeProfiles> >> > >>>> > <activeProfile>inject-accumulo-home</activeProfile> >> > >>>> > </activeProfiles> >> > >>>> > >> > >>>> > You may notice that files that were previously ignored in the SCM >> > are >> > >>>> > now recognized as unversioned. You can simply move these to your >> > >>>> > desired DEV_ACCUMULO_HOME location. I would hope that you do not >> > >>>> > simply ignore these changes and re-add all these unversioned files >> > >>>> > back to svn:ignore/.gitignore, and respect the goal of trying to >> > >>>> > minimize maintenance of all the exceptions in the build/packaging >> > that >> > >>>> > these unversioned files dirtying the workspace create. >> > >>>> > >> > >>>> > Right now, the way this directory gets created/used, is pretty >> > clunky, >> > >>>> > but it sets things up, so I can work towards doing it more cleanly >> > >>>> > with the maven-assembly-plugin. There shouldn't be any further >> > >>>> > noticeable changes in terms of the method for activating this >> > external >> > >>>> > DEV_ACCUMULO_HOME directory. If there's something I missed (I'm >> > aware >> > >>>> > currently of the randomwalk configuration files, and the >> > >>>> > fake_disk_failure.so in the system tests) that show up in the >> source >> > >>>> > tree as unversioned files, please let me know, and I'll work to >> get >> > >>>> > them modified so they work in a way that doesn't dirty the >> workspace >> > >>>> > and continue to cause difficulty for packaging. >> > >>>> > >> > >>>> > -- >> > >>>> > Christopher L Tubbs II >> > >>>> > http://gravatar.com/ctubbsii >> > >>>> >> > >>
