Hello Vincent,
Vincent Massol schrieb:
No worries, at times I'm preoccupied with something else myself, so I don't mind.Hi Thomas,
Sorry for the extremely long delay. It's a pity I wasn't more responsive as
you really seem to understand Cactus well and that's not common! :-). Anyway
see below my answers/comments.
...
3.) When using the ant scripts supplied on my XP installation, I had
some problems
with the classpath, that seems to rely on GUMP for including the
ant.jar. I'm not familiar
with neither GUMP nor Maven, so fixed it, by simply changing the build
files for integration/ant
and documentation.
I'm not sure what problem you've had. Was is a problem when running Ant?
Well, looking through the directories and build files, I couldn't help
but notice, that somebody added maven project descriptors (maven.xml,
project.xml) to the source tree, for a purpose, I assume.
:-) This is because we had started to migrate to Maven for our build but we've not finished and this is a work in progress. I'm not even sure the Maven build still works as it's not been touched for a while.
Than again, in integration/ant/build.xml you'll find the lines:
<path id="project.classpath"> <pathelement location="${commons.logging.jar}"/> <pathelement location="${xerces.jar}"/> <pathelement location="${xmlapis.jar}"/>
<!-- Required for Gump --> <pathelement location="${java.class.path}"/>
</path>
The embedded comment clearly relates to a comment I saw somewhere
on apache, that Gump uses the ant classpath ignore feature, to get the
dependencies right.
Yes, that's the reason. It's because Gump works by controlling the classpaths used by Ant (using the ignore* property you mention). This is because it builds all others project from their repository and its goal is to ensure all projects work with latest built versions. Thus in the code snippet above, Gump will ignore the commons.logging.jar, xerces.jar and xlmapis.jar jars.
On my machine, this broke the build, because
'location' expects
a single directory or file, but ${java.class.path} contained a semicolon
separated path.
The thing that has to be present there is the ant.jar.
Strange that it broke your build. Which version of Ant are you using? Which
OS are you running on? When you say it breaks your build, are you talking
about the Ant build or building using Gump?
I built the patch using ANT 1.6.2.
Wether it is going to work is depending on the setting of the classpath of the machine or process.Similarily, you need this to be present in the classpath of the javac
task within
documentatition/build.xml.
Strange again as it works fine here. I would be curious to find the reason
for these 2 differences we have...
If ${java.class.path}== <ant.home>/lib/ant.jar, everything would be fine, since this qualifies
as a 'location' in the eyes of ant.
But if you got something more complicated like ${java.class.path}== <ant.home>/lib/ant.jar;<some other jars and directories>
ant tries to see the path as a single location, which obviously wouldn't exist on the file system.
changing 'location' to 'path' will remedy this, so any spurious entries on the classpath
will not break the build, as long as the proper ant.jar is found early enough on the classpath.
I tested it using my two maschines and a build file from a different project of mine.[snip]
Thanks a lot. Having some test to prove that it works would be cool but I
cannot think of an easy way to perform an integration test... Let me know if
you have an idea.
Obviously, a test like this would break the portability of the tests.
Having both the ant script and the server on the same maschine, you might dupplicate
some of the existing tests, and use server="localhost" and/or server="127.0.0.1".
While this doesn't really demonstrate remoting, it demonstrates, that the change
doesn't break anything existing.
If you go to the length of finding out the name or ip of the maschine the test is running
on, you might use them instead, which would avoid using the loop back interface.
But I heared, that there are some issues with that for certain combinations
of JVMs and Unixs OSs, where the java.net. classes would invariably return
the loop back interface...
Cheers, Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
