Dealing with big, slow, unpacks

[Benson Margulies <bi...@gmail.com>]

I just spend an afternoon wrestling with the release plugin. Much of
my trouble was a self-inflicted misunderstanding of
<preparationGoals/> (*), but that wasn't what sent me down the path to
begin with.

I have a set of maven projects that build, amongst several other
things, a set of daemons. Each daemon is independently packaged using
the assembly plugin using the Tanuki tools, to which we have a
license.

The collection of Tanuki shared libs and other goodies is not small.
So I compressed it and pushed it to Nexus as an artifact of type
.tar.bz2.

Now, the straightforward thing to do, and indeed what I did to begin
with, was to simply list the Tanuki stuff in the assembly descriptor
for each daemon.

This made build-from-clean quite slow, as the build had to uncompress
the tarball every time.

So, I had an inspiration. Unpack it once into the tree in one project,
and then use the magic of '..' to reference it in the other project.
Which was fine, until I went to run the release plugin, which added
'target/checkout' to the path, and there went the .. counting.
Eventually, I got this under control, but only after some other
mishaps that were quite time consuming.

So, oh gurus of the maven way, where did I depart from the one true
path? Did I sin mortally by '..'-ing out of the basedir? Is there any
good way to attack the speed issue I set out to attack, or should I
have just lived with the time (and space) to unpack this stuff over
and over?

[*] My unit tests are also quite time consuming, so the debugging
process of multiple attempts at the release process was intolerably
slow with them in release:prepare, and I did not realize for quite
some time and -X reading that prepare forked another copy of maven ...
 I thought, incorrectly, that only perform did that.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Jörg Schaible <jo...@scalaris.com>]

Hi,

Benson Margulies wrote:

> There are 80 total files.
> 
> It would be a pretty big job to script the conversion of the
> distribution from Tanuki into many little artifacts, though I do see
> your point that achieving this result would get rid of the tarry
> overhead.

Maybe you can take a look into the code of the nar plugin. That one 
generates also Java archives for the native shared/static libraries along 
with a JNI jars and C headers. When referenceing such a beast from another 
project it will unpack that jar in the local repository and copy files from 
there.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Benson Margulies <bi...@gmail.com>]

There are 80 total files.

It would be a pretty big job to script the conversion of the
distribution from Tanuki into many little artifacts, though I do see
your point that achieving this result would get rid of the tarry
overhead.


On Wed, Dec 22, 2010 at 7:55 AM, Anders Hammar <an...@hammar.net> wrote:
> Ok, adding config files as separate artifacts might not be the best thing.
> The native libraries I would add as separate artifacts though. Then you
> don't have to unpack that, which would speed things up.
> How many files are there in the tar file?
>
> /Anders
>
> On Wed, Dec 22, 2010 at 13:48, Benson Margulies <bi...@gmail.com>wrote:
>
>> On Wed, Dec 22, 2010 at 4:46 AM, Anders Hammar <an...@hammar.net> wrote:
>> > Yes, ".."-ing out of basedir is a sin. A Maven project should be
>> > self-contained.
>> >
>> > Regarding your approach, I don't follow. Why did you create a tar of the
>> > libs? Why not keep them as separate artifacts and then you don't have to
>> > uncompress the tar file? Just list each of the dependencies in your
>> assembly
>> > project and you're set.
>> > I haven't tried it myself, but it looks like you can use Component
>> > Descriptors in your assemblies to just create one descriptor for the
>> Tanuki
>> > stuff that you can reuse in all assemblies.
>>
>> They aren't 'libs' in the sense you mean. They are shell scripts,
>> configuration files, native libraries, etc. All of it has to be part
>> of the packaged assembly. In any case, I don't see the different
>> between one maven artifact tarballing the pile of them and 27 maven
>> artifacts.
>>
>> I *did* use a component descriptor. The problem is not config file
>> management, it is that the time it takes Maven to run the equivalent
>> of 'tar jxf' and unpack 16MB of stuff, 12 times, is a lot of time.
>>
>> >
>> > /Anders
>> >
>> > On Tue, Dec 21, 2010 at 22:29, Benson Margulies <bimargulies@gmail.com
>> >wrote:
>> >
>> >> I just spend an afternoon wrestling with the release plugin. Much of
>> >> my trouble was a self-inflicted misunderstanding of
>> >> <preparationGoals/> (*), but that wasn't what sent me down the path to
>> >> begin with.
>> >>
>> >> I have a set of maven projects that build, amongst several other
>> >> things, a set of daemons. Each daemon is independently packaged using
>> >> the assembly plugin using the Tanuki tools, to which we have a
>> >> license.
>> >>
>> >> The collection of Tanuki shared libs and other goodies is not small.
>> >> So I compressed it and pushed it to Nexus as an artifact of type
>> >> .tar.bz2.
>> >>
>> >> Now, the straightforward thing to do, and indeed what I did to begin
>> >> with, was to simply list the Tanuki stuff in the assembly descriptor
>> >> for each daemon.
>> >>
>> >> This made build-from-clean quite slow, as the build had to uncompress
>> >> the tarball every time.
>> >>
>> >> So, I had an inspiration. Unpack it once into the tree in one project,
>> >> and then use the magic of '..' to reference it in the other project.
>> >> Which was fine, until I went to run the release plugin, which added
>> >> 'target/checkout' to the path, and there went the .. counting.
>> >> Eventually, I got this under control, but only after some other
>> >> mishaps that were quite time consuming.
>> >>
>> >> So, oh gurus of the maven way, where did I depart from the one true
>> >> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
>> >> good way to attack the speed issue I set out to attack, or should I
>> >> have just lived with the time (and space) to unpack this stuff over
>> >> and over?
>> >>
>> >> [*] My unit tests are also quite time consuming, so the debugging
>> >> process of multiple attempts at the release process was intolerably
>> >> slow with them in release:prepare, and I did not realize for quite
>> >> some time and -X reading that prepare forked another copy of maven ...
>> >>  I thought, incorrectly, that only perform did that.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Anders Hammar <an...@hammar.net>]

Ok, adding config files as separate artifacts might not be the best thing.
The native libraries I would add as separate artifacts though. Then you
don't have to unpack that, which would speed things up.
How many files are there in the tar file?

/Anders

On Wed, Dec 22, 2010 at 13:48, Benson Margulies <bi...@gmail.com>wrote:

> On Wed, Dec 22, 2010 at 4:46 AM, Anders Hammar <an...@hammar.net> wrote:
> > Yes, ".."-ing out of basedir is a sin. A Maven project should be
> > self-contained.
> >
> > Regarding your approach, I don't follow. Why did you create a tar of the
> > libs? Why not keep them as separate artifacts and then you don't have to
> > uncompress the tar file? Just list each of the dependencies in your
> assembly
> > project and you're set.
> > I haven't tried it myself, but it looks like you can use Component
> > Descriptors in your assemblies to just create one descriptor for the
> Tanuki
> > stuff that you can reuse in all assemblies.
>
> They aren't 'libs' in the sense you mean. They are shell scripts,
> configuration files, native libraries, etc. All of it has to be part
> of the packaged assembly. In any case, I don't see the different
> between one maven artifact tarballing the pile of them and 27 maven
> artifacts.
>
> I *did* use a component descriptor. The problem is not config file
> management, it is that the time it takes Maven to run the equivalent
> of 'tar jxf' and unpack 16MB of stuff, 12 times, is a lot of time.
>
> >
> > /Anders
> >
> > On Tue, Dec 21, 2010 at 22:29, Benson Margulies <bimargulies@gmail.com
> >wrote:
> >
> >> I just spend an afternoon wrestling with the release plugin. Much of
> >> my trouble was a self-inflicted misunderstanding of
> >> <preparationGoals/> (*), but that wasn't what sent me down the path to
> >> begin with.
> >>
> >> I have a set of maven projects that build, amongst several other
> >> things, a set of daemons. Each daemon is independently packaged using
> >> the assembly plugin using the Tanuki tools, to which we have a
> >> license.
> >>
> >> The collection of Tanuki shared libs and other goodies is not small.
> >> So I compressed it and pushed it to Nexus as an artifact of type
> >> .tar.bz2.
> >>
> >> Now, the straightforward thing to do, and indeed what I did to begin
> >> with, was to simply list the Tanuki stuff in the assembly descriptor
> >> for each daemon.
> >>
> >> This made build-from-clean quite slow, as the build had to uncompress
> >> the tarball every time.
> >>
> >> So, I had an inspiration. Unpack it once into the tree in one project,
> >> and then use the magic of '..' to reference it in the other project.
> >> Which was fine, until I went to run the release plugin, which added
> >> 'target/checkout' to the path, and there went the .. counting.
> >> Eventually, I got this under control, but only after some other
> >> mishaps that were quite time consuming.
> >>
> >> So, oh gurus of the maven way, where did I depart from the one true
> >> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
> >> good way to attack the speed issue I set out to attack, or should I
> >> have just lived with the time (and space) to unpack this stuff over
> >> and over?
> >>
> >> [*] My unit tests are also quite time consuming, so the debugging
> >> process of multiple attempts at the release process was intolerably
> >> slow with them in release:prepare, and I did not realize for quite
> >> some time and -X reading that prepare forked another copy of maven ...
> >>  I thought, incorrectly, that only perform did that.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Dealing with big, slow, unpacks

[Benson Margulies <bi...@gmail.com>]

On Wed, Dec 22, 2010 at 4:46 AM, Anders Hammar <an...@hammar.net> wrote:
> Yes, ".."-ing out of basedir is a sin. A Maven project should be
> self-contained.
>
> Regarding your approach, I don't follow. Why did you create a tar of the
> libs? Why not keep them as separate artifacts and then you don't have to
> uncompress the tar file? Just list each of the dependencies in your assembly
> project and you're set.
> I haven't tried it myself, but it looks like you can use Component
> Descriptors in your assemblies to just create one descriptor for the Tanuki
> stuff that you can reuse in all assemblies.

They aren't 'libs' in the sense you mean. They are shell scripts,
configuration files, native libraries, etc. All of it has to be part
of the packaged assembly. In any case, I don't see the different
between one maven artifact tarballing the pile of them and 27 maven
artifacts.

I *did* use a component descriptor. The problem is not config file
management, it is that the time it takes Maven to run the equivalent
of 'tar jxf' and unpack 16MB of stuff, 12 times, is a lot of time.

>
> /Anders
>
> On Tue, Dec 21, 2010 at 22:29, Benson Margulies <bi...@gmail.com>wrote:
>
>> I just spend an afternoon wrestling with the release plugin. Much of
>> my trouble was a self-inflicted misunderstanding of
>> <preparationGoals/> (*), but that wasn't what sent me down the path to
>> begin with.
>>
>> I have a set of maven projects that build, amongst several other
>> things, a set of daemons. Each daemon is independently packaged using
>> the assembly plugin using the Tanuki tools, to which we have a
>> license.
>>
>> The collection of Tanuki shared libs and other goodies is not small.
>> So I compressed it and pushed it to Nexus as an artifact of type
>> .tar.bz2.
>>
>> Now, the straightforward thing to do, and indeed what I did to begin
>> with, was to simply list the Tanuki stuff in the assembly descriptor
>> for each daemon.
>>
>> This made build-from-clean quite slow, as the build had to uncompress
>> the tarball every time.
>>
>> So, I had an inspiration. Unpack it once into the tree in one project,
>> and then use the magic of '..' to reference it in the other project.
>> Which was fine, until I went to run the release plugin, which added
>> 'target/checkout' to the path, and there went the .. counting.
>> Eventually, I got this under control, but only after some other
>> mishaps that were quite time consuming.
>>
>> So, oh gurus of the maven way, where did I depart from the one true
>> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
>> good way to attack the speed issue I set out to attack, or should I
>> have just lived with the time (and space) to unpack this stuff over
>> and over?
>>
>> [*] My unit tests are also quite time consuming, so the debugging
>> process of multiple attempts at the release process was intolerably
>> slow with them in release:prepare, and I did not realize for quite
>> some time and -X reading that prepare forked another copy of maven ...
>>  I thought, incorrectly, that only perform did that.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Anders Hammar <an...@hammar.net>]

Yes, ".."-ing out of basedir is a sin. A Maven project should be
self-contained.

Regarding your approach, I don't follow. Why did you create a tar of the
libs? Why not keep them as separate artifacts and then you don't have to
uncompress the tar file? Just list each of the dependencies in your assembly
project and you're set.
I haven't tried it myself, but it looks like you can use Component
Descriptors in your assemblies to just create one descriptor for the Tanuki
stuff that you can reuse in all assemblies.

/Anders

On Tue, Dec 21, 2010 at 22:29, Benson Margulies <bi...@gmail.com>wrote:

> I just spend an afternoon wrestling with the release plugin. Much of
> my trouble was a self-inflicted misunderstanding of
> <preparationGoals/> (*), but that wasn't what sent me down the path to
> begin with.
>
> I have a set of maven projects that build, amongst several other
> things, a set of daemons. Each daemon is independently packaged using
> the assembly plugin using the Tanuki tools, to which we have a
> license.
>
> The collection of Tanuki shared libs and other goodies is not small.
> So I compressed it and pushed it to Nexus as an artifact of type
> .tar.bz2.
>
> Now, the straightforward thing to do, and indeed what I did to begin
> with, was to simply list the Tanuki stuff in the assembly descriptor
> for each daemon.
>
> This made build-from-clean quite slow, as the build had to uncompress
> the tarball every time.
>
> So, I had an inspiration. Unpack it once into the tree in one project,
> and then use the magic of '..' to reference it in the other project.
> Which was fine, until I went to run the release plugin, which added
> 'target/checkout' to the path, and there went the .. counting.
> Eventually, I got this under control, but only after some other
> mishaps that were quite time consuming.
>
> So, oh gurus of the maven way, where did I depart from the one true
> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
> good way to attack the speed issue I set out to attack, or should I
> have just lived with the time (and space) to unpack this stuff over
> and over?
>
> [*] My unit tests are also quite time consuming, so the debugging
> process of multiple attempts at the release process was intolerably
> slow with them in release:prepare, and I did not realize for quite
> some time and -X reading that prepare forked another copy of maven ...
>  I thought, incorrectly, that only perform did that.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

RE: Dealing with big, slow, unpacks

[Lindsay Smith <li...@coretech.co.nz>]

We've encountered the slow unpack problem as well - it's related to making exec calls for each file (chmod or something).  We've resorted to an ant task for the unpack as it does it at 'normal' speed.

Lindsay

> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Wednesday, 22 December 2010 10:29 a.m.
> To: Maven Users List
> Subject: Dealing with big, slow, unpacks
> 
> I just spend an afternoon wrestling with the release plugin. Much of
> my trouble was a self-inflicted misunderstanding of
> <preparationGoals/> (*), but that wasn't what sent me down the path to
> begin with.
> 
> I have a set of maven projects that build, amongst several other
> things, a set of daemons. Each daemon is independently packaged using
> the assembly plugin using the Tanuki tools, to which we have a
> license.
> 
> The collection of Tanuki shared libs and other goodies is not small.
> So I compressed it and pushed it to Nexus as an artifact of type
> .tar.bz2.
> 
> Now, the straightforward thing to do, and indeed what I did to begin
> with, was to simply list the Tanuki stuff in the assembly descriptor
> for each daemon.
> 
> This made build-from-clean quite slow, as the build had to uncompress
> the tarball every time.
> 
> So, I had an inspiration. Unpack it once into the tree in one project,
> and then use the magic of '..' to reference it in the other project.
> Which was fine, until I went to run the release plugin, which added
> 'target/checkout' to the path, and there went the .. counting.
> Eventually, I got this under control, but only after some other
> mishaps that were quite time consuming.
> 
> So, oh gurus of the maven way, where did I depart from the one true
> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
> good way to attack the speed issue I set out to attack, or should I
> have just lived with the time (and space) to unpack this stuff over
> and over?
> 
> [*] My unit tests are also quite time consuming, so the debugging
> process of multiple attempts at the release process was intolerably
> slow with them in release:prepare, and I did not realize for quite
> some time and -X reading that prepare forked another copy of maven ...
>  I thought, incorrectly, that only perform did that.

Re: Dealing with big, slow, unpacks

[Benson Margulies <bi...@gmail.com>]

oho, very clever.


On Wed, Dec 22, 2010 at 10:32 AM, Marshall Schor <ms...@schor.com> wrote:
> Here's another way (see below)
>
> On 12/21/2010 4:29 PM, Benson Margulies wrote:
>> I just spend an afternoon wrestling with the release plugin. Much of
>> my trouble was a self-inflicted misunderstanding of
>> <preparationGoals/> (*), but that wasn't what sent me down the path to
>> begin with.
>>
>> I have a set of maven projects that build, amongst several other
>> things, a set of daemons. Each daemon is independently packaged using
>> the assembly plugin using the Tanuki tools, to which we have a
>> license.
>>
>> The collection of Tanuki shared libs and other goodies is not small.
>> So I compressed it and pushed it to Nexus as an artifact of type
>> .tar.bz2.
>>
>> Now, the straightforward thing to do, and indeed what I did to begin
>> with, was to simply list the Tanuki stuff in the assembly descriptor
>> for each daemon.
>>
>> This made build-from-clean quite slow, as the build had to uncompress
>> the tarball every time.
>>
>> So, I had an inspiration. Unpack it once into the tree in one project,
>> and then use the magic of '..' to reference it in the other project.
>> Which was fine, until I went to run the release plugin, which added
>> 'target/checkout' to the path, and there went the .. counting.
>> Eventually, I got this under control, but only after some other
>> mishaps that were quite time consuming.
>
> We've made this kind of approach work in our POMs.  We  keep the idea of
> unpacking it once, but do it to a more general spot, such as a place in your .m2
> repo.
>
> You can use the property ${settings.localRepository} in your POM to make this
> work in general.
>
> -Marshall Schor
>
>> So, oh gurus of the maven way, where did I depart from the one true
>> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
>> good way to attack the speed issue I set out to attack, or should I
>> have just lived with the time (and space) to unpack this stuff over
>> and over?
>>
>> [*] My unit tests are also quite time consuming, so the debugging
>> process of multiple attempts at the release process was intolerably
>> slow with them in release:prepare, and I did not realize for quite
>> some time and -X reading that prepare forked another copy of maven ...
>>  I thought, incorrectly, that only perform did that.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Marshall Schor <ms...@schor.com>]

Also, I think the dependency unpack goal can check for dates, and skip the
unpack if the version in the local .m2 repo is up to date

-Marshall

On 12/22/2010 10:32 AM, Marshall Schor wrote:
> Here's another way (see below)
>
> On 12/21/2010 4:29 PM, Benson Margulies wrote:
>> I just spend an afternoon wrestling with the release plugin. Much of
>> my trouble was a self-inflicted misunderstanding of
>> <preparationGoals/> (*), but that wasn't what sent me down the path to
>> begin with.
>>
>> I have a set of maven projects that build, amongst several other
>> things, a set of daemons. Each daemon is independently packaged using
>> the assembly plugin using the Tanuki tools, to which we have a
>> license.
>>
>> The collection of Tanuki shared libs and other goodies is not small.
>> So I compressed it and pushed it to Nexus as an artifact of type
>> .tar.bz2.
>>
>> Now, the straightforward thing to do, and indeed what I did to begin
>> with, was to simply list the Tanuki stuff in the assembly descriptor
>> for each daemon.
>>
>> This made build-from-clean quite slow, as the build had to uncompress
>> the tarball every time.
>>
>> So, I had an inspiration. Unpack it once into the tree in one project,
>> and then use the magic of '..' to reference it in the other project.
>> Which was fine, until I went to run the release plugin, which added
>> 'target/checkout' to the path, and there went the .. counting.
>> Eventually, I got this under control, but only after some other
>> mishaps that were quite time consuming.
> We've made this kind of approach work in our POMs.  We  keep the idea of
> unpacking it once, but do it to a more general spot, such as a place in your .m2
> repo.
>
> You can use the property ${settings.localRepository} in your POM to make this
> work in general.
>
> -Marshall Schor
>
>> So, oh gurus of the maven way, where did I depart from the one true
>> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
>> good way to attack the speed issue I set out to attack, or should I
>> have just lived with the time (and space) to unpack this stuff over
>> and over?
>>
>> [*] My unit tests are also quite time consuming, so the debugging
>> process of multiple attempts at the release process was intolerably
>> slow with them in release:prepare, and I did not realize for quite
>> some time and -X reading that prepare forked another copy of maven ...
>>  I thought, incorrectly, that only perform did that.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dealing with big, slow, unpacks

[Marshall Schor <ms...@schor.com>]

Here's another way (see below)

On 12/21/2010 4:29 PM, Benson Margulies wrote:
> I just spend an afternoon wrestling with the release plugin. Much of
> my trouble was a self-inflicted misunderstanding of
> <preparationGoals/> (*), but that wasn't what sent me down the path to
> begin with.
>
> I have a set of maven projects that build, amongst several other
> things, a set of daemons. Each daemon is independently packaged using
> the assembly plugin using the Tanuki tools, to which we have a
> license.
>
> The collection of Tanuki shared libs and other goodies is not small.
> So I compressed it and pushed it to Nexus as an artifact of type
> .tar.bz2.
>
> Now, the straightforward thing to do, and indeed what I did to begin
> with, was to simply list the Tanuki stuff in the assembly descriptor
> for each daemon.
>
> This made build-from-clean quite slow, as the build had to uncompress
> the tarball every time.
>
> So, I had an inspiration. Unpack it once into the tree in one project,
> and then use the magic of '..' to reference it in the other project.
> Which was fine, until I went to run the release plugin, which added
> 'target/checkout' to the path, and there went the .. counting.
> Eventually, I got this under control, but only after some other
> mishaps that were quite time consuming.

We've made this kind of approach work in our POMs.  We  keep the idea of
unpacking it once, but do it to a more general spot, such as a place in your .m2
repo.

You can use the property ${settings.localRepository} in your POM to make this
work in general.

-Marshall Schor

> So, oh gurus of the maven way, where did I depart from the one true
> path? Did I sin mortally by '..'-ing out of the basedir? Is there any
> good way to attack the speed issue I set out to attack, or should I
> have just lived with the time (and space) to unpack this stuff over
> and over?
>
> [*] My unit tests are also quite time consuming, so the debugging
> process of multiple attempts at the release process was intolerably
> slow with them in release:prepare, and I did not realize for quite
> some time and -X reading that prepare forked another copy of maven ...
>  I thought, incorrectly, that only perform did that.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org