Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> assembly pom


Copy link to this message
-
Re: assembly pom
On Wed, Mar 14, 2012 at 11:02 AM, John Vines <[EMAIL PROTECTED]> wrote:
> We run it in the svn structure, which makes testing easy. I would like to
> be able to avoid building and packaging it just to run it.
How about if we just take the config out of the top-level pom, and put
it into the specific poms that actually build the jars that belong in
lib? That way the examples won't go dropping jars in surprising
places.

>
> Sent from my phone, so pardon the typos and brevity.
> On Mar 14, 2012 1:47 PM, "Benson Margulies" <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Mar 14, 2012 at 9:31 AM, Billie J Rinaldi
>> <[EMAIL PROTECTED]> wrote:
>> > If the lib directory were moved to target/lib, where would it appear in
>> the tar.gz that is created?  It is convenient to have the locations match,
>> because then we can run testing out of our accumulo workspaces.
>>
>> How important is the 'the tree always looks like an installation'? I'm
>> thinking about other ways than the current jar plugin business to
>> accomplish this, but if it's not important, it would be easiest to let
>> the assemble project do all of this. If it is important, I'll see what
>> I can come up with. If the default execution of the assemble project
>> was to *rapidly* copy everything into place, for example, and only the
>> -Passemble profile bothered with tarballs?
>>
>> >
>> > Billie
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Benson Margulies" <[EMAIL PROTECTED]>
>> >> To: [EMAIL PROTECTED]
>> >> Sent: Tuesday, March 13, 2012 7:10:33 PM
>> >> Subject: Re: assembly pom
>> >> On Tue, Mar 13, 2012 at 6:25 PM, David Medinets
>> >> <[EMAIL PROTECTED]> wrote:
>> >> > On Tue, Mar 13, 2012 at 4:21 PM, Keith Turner <[EMAIL PROTECTED]>
>> >> > wrote:
>> >> >> I do not know how it happens, but somehow the jars generated by
>> >> >> some
>> >> >> of the child projects end up in the top level lib dir. Could that
>> >> >> be
>> >> >> what this was doing?
>> >> >
>> >> > The question is answered in the top-level pom.xml file. There is a
>> >> > maven-jar-plugin section that sets outputDirectory to be ../../lib.
>> >> > Thus the jar files are placed into the top-level lib directory. I'd
>> >> > suggest this value be changed to ../../target/lib. And after the
>> >> > extra
>> >> > src level is removed, then ../target/lib or simply target/lib.
>> >>
>> >> Unless we want to do all this the 'conventional' way ... which would
>> >> have the disadvantage of not building up the lib directory (or the
>> >> target/lib directory) incrementally.
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB