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]
