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