accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: svn:ignore .gitignore and ACCUMULO-935
Date Thu, 06 Jun 2013 18:07:51 GMT
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.medinets@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.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
View raw message