Done. Cactus now has a 'gump' target which is the equivalent of the 'all'
one but it does not call the 'clean' target.
Thanks
-Vincent
----- Original Message -----
From: "Sam Ruby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 7:32 PM
Subject: Re: [GUMP][Cactus] commons-cactus-23
> Vincent Massol wrote:
> >
> > Would it be possible to change back the target for commons-cactus-23
from
> > "jar" to "all" ? I sent an email on jakarta-commons a few days ago to
> > explain that I made the changes you requested for GUMP and explained
where
> > to find the dist files.
>
> In due time. Let me explain.
>
> First, despite numerous requests, you have *not* make the change that I
> requested. My request was simple. It was implementable. All I asked was
> that you create a single target which looks exactly like the "all" target
> with one crucial difference - it does not depend directly or indirectly on
> the clean target.
>
> You have made several changes in an attempt to satisfy my request. Each
> time, you gave me something different than what I asked for. Each time it
> took several hours of my time to identify why it would not work.
>
> For the moment, I have something that works for me. And a much bigger
> problem that I trying to resolve - namely keeping up with the changes in
> the build process for Avalon. Once those are resolved, I do plan to come
> back to cactus. Of course, I would gladly do so sooner, if you would
> simply do what I requested. ;-)
>
> More detail on the constraints I am currently operating under. I do the
> bulk of my development on either my Windows laptop or my Windows desktop.
> I do much of my testing on nagoya (a Solaris box). And the official runs
> are done on a Linux box.
>
> In this case, I can do no development or testing on Windows. When D:
> \jakarta\jakarta-commons\cactus\target\commons-cactus-ant.jar is in my
> classpath, and the first step of a build of commons-cactus-22 involves
> deleting the target directory, then the build immediately fails with a
> sharing violation. I'm not sure why I don't see this on Unix platforms,
> but I don't.
>
> I also am reluctant to do development or testing on nagoya at this time.
> The reason is that it is machine which is shared with others. At a prior
> point in time running the cactus tests interfered with some of the other
> servers on the machine (specifically: it took them down). I am aware that
> you have made changes to avoid this problem, but I would like to
coordinate
> testing this with a number of other people (Pier in particular) and as I
> indicated above, this is not yet top of my priority list.
>
> This leaves my "production" machine. I normally avoid doing any
> development work on that machine for various reasons. But if this is
> required in order to verify that what you have done will address my
> problem (on Unix, only mind you - the problem will still occur on Windows)
> or identify the next problem, then I will do it - again in due time.
>
> Summary:
>
> Implement my reasonable request, and this will be resolved quickly. If
> not, then I will get around to it when the builds start running clean.
>
> Sorry to be so difficult. But I have requested this multiple times. And
I
> do have something that works for me at the moment.
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
