> -----Original Message-----
> From: Th. Schapitz [mailto:[EMAIL PROTECTED]
> Sent: dimanche 30 janvier 2005 11:30
> To: Cactus Developers List
> Subject: Re: Remote Cactus
>
> Hello Vincent,
[snip]
> Wether it is going to work is depending on the setting of the classpath
> of the machine or process.
> 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.
Hmm... I've applied your change but I still don't know why it works for me
and not for you as I also happen to have lots of entries on my
${java.class.path}:
c:\apps\apache-ant-1.6.2\lib\ant-launcher.jar;C:\apps\apache-ant-1.6.2\lib\a
nt-antlr.jar;C:\apps\apache-an
t-1.6.2\lib\ant-apache-bcel.jar;C:\apps\apache-ant-1.6.2\lib\ant-apache-bsf.
jar;C:\apps\apache-ant-1.6.2\lib\ant-apache-log4j.jar;
C:\apps\apache-ant-1.6.2\lib\ant-apache-oro.jar;C:\apps\apache-ant-1.6.2\lib
\ant-apache-regexp.jar;C:\apps\apache-ant-1.6.2\lib\an
t-apache-resolver.jar;C:\apps\apache-ant-1.6.2\lib\ant-commons-logging.jar;C
:\apps\apache-ant-1.6.2\lib\ant-commons-net.jar;C:\app
s\apache-ant-1.6.2\lib\ant-icontract.jar;C:\apps\apache-ant-1.6.2\lib\ant-ja
i.jar;C:\apps\apache-ant-1.6.2\lib\ant-javamail.jar;C:
\apps\apache-ant-1.6.2\lib\ant-jdepend.jar;C:\apps\apache-ant-1.6.2\lib\ant-
jmf.jar;C:\apps\apache-ant-1.6.2\lib\ant-jsch.jar;C:\a
pps\apache-ant-1.6.2\lib\ant-junit.jar;C:\apps\apache-ant-1.6.2\lib\ant-laun
cher.jar;C:\apps\apache-ant-1.6.2\lib\ant-netrexx.jar;
C:\apps\apache-ant-1.6.2\lib\ant-nodeps.jar;C:\apps\apache-ant-1.6.2\lib\ant
-starteam.jar;C:\apps\apache-ant-1.6.2\lib\ant-stylebo
ok.jar;C:\apps\apache-ant-1.6.2\lib\ant-swing.jar;C:\apps\apache-ant-1.6.2\l
ib\ant-trax.jar;C:\apps\apache-ant-1.6.2\lib\ant-vaj.j
ar;C:\apps\apache-ant-1.6.2\lib\ant-weblogic.jar;C:\apps\apache-ant-1.6.2\li
b\ant-xalan1.jar;C:\apps\apache-ant-1.6.2\lib\ant-xslp
.jar;C:\apps\apache-ant-1.6.2\lib\ant.jar;C:\apps\apache-ant-1.6.2\lib\clove
r-1.2.3.jar;C:\apps\apache-ant-1.6.2\lib\junit-3.8.1.j
ar;C:\apps\apache-ant-1.6.2\lib\xercesImpl.jar;C:\apps\apache-ant-1.6.2\lib\
xml-apis.jar;c:\j2sdk1.4.2_05\lib\tools.jar
> >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.
> >
> >
> I tested it using my two maschines and a build file from a different
> project of mine.
> 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...
Yes... I think I'll leave it as it is now and we'll see. Having some
well-placed unit tests should be enough for this case. If someone finds an
issue we'll investigate more in testing... :-)
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
