accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: svn:ignore .gitignore and ACCUMULO-935
Date Thu, 06 Jun 2013 16:56:11 GMT
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.rinaldi@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 <ctubbsii@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 <ctubbsii@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 <ctubbsii@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 <dlyle65535@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 <ctubbsii@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 <ctubbsii@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
> > >>>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message