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 > > >>>> > > >
