Stefano Mazzocchi wrote:
all right, here is what I did (precisely):
$ ssh www.cocoondev.org $ cd /usr/serverlocal/gump/cocoon-2.1 $ cvs -q update $ cd /usr/serverlocal/gump/jakarta-gump $ cvs -q update $ cd $ build gump clean $ build gump verify $ build gump scripts $ build cocoon clean $ build cocoon gump-core
and I get a bunch of compilation errors.
If I run
$ build cocoon -v gump-core
I get
...
dropping /usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar from path as it doesn't exist
Don't go looking for hard answers to easy problems. There's a perfectly mundane explanation for this. Excalibur-compatibility's build failed last night.
http://gump.cocoondev.org/excalibur-compatibility.html
Looking closer, there actually are deeper problems. Ones that I don't have ready answers for.
First is that the path is constructed improperly. At some point the base path of the cocoon directory is prepended to the fully qualified path to the excalibur jar. I'm not sure why or when this is done. Looking at the generated build.sh file, the classpath is set up correctly, and no variables are passed on the ant command that would explain this. I've grepped the various .properties and .xml files in the cocoon directory and don't see how the excalibur jars are referenced.
Stefano, if you could take a look at this, I'd appreciate it. No need to look into the xslt files... simply load build.sh into your favorite editor and look for "cocoon;" (with the semicolon). Immediately after this you will see the classpath being set up and then the ant call. Tell me is you see anything amis.
Even if this were corrected, however, I do see a jar in the avalon-excalibur/compatibility/build/lib directory. What's odd is that it was built this morning, but has yesterday's date on it. This I can't explain either.
- Sam Ruby
