----- 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.
Sam, I'm sorry if I'm being difficult but I can assure you I'm not doing it
on purpose ! I'm trying my best to help everytime. As far as I know you only
asked me once to create a new target without the clean. What you asked
previously was to separate the build process in several ones : one for
building the Cactus custom Ant tasks, one for Cactus-22 and one for
Cactus-23. I told you that I agreed with it but I would need a bit more time
to explode the build in several ones. In the meantime, you created a new
GUMP definition for Cactus-ant and it seemed to work so I did not press this
issue (and I'm not sure we need several builds - because then we loose
dependencies).
Regarding your last request, you told me that you move from 'all' to 'jar'
*because* when cactus-23 was running it was erasing the files generated by
cactus-22. Based on this information I provided a mechanism that would not
erase the files. Now, I always try to understand what I do (I have the bad
habit that I like to learn and to understand what I do ... which is why
probably you're finding me difficult). What you are saying now, is that
there were some other reasons (namely the cactus custom ant task jar in the
classpath) underlying your request.
OK, fine. I *do* want to resolve this issue ASAP. Also, I do not want to
make your life more difficult as I know you have a lot work on other issues.
>
> 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.
>
sorry.
> 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.
ok. I'll create a 'gump' target right now which does not call 'clean' at
all. However, I'd like to go over it with you, when you have some time, in
order to make something clean.
Thanks
> - Sam Ruby
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
