Geoff Howard wrote:
Timothy Larson wrote:
I just downloaded a new snapshot, and now the build fails with this message:
BUILD FAILED file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441: UnknownHostException. Probable cause: The parser is trying to resolve a dtd from the internet and no connection exists. You can either connect to the internet during the build, or patch XConfToolTask.java to ignore DTD declarations when your parser is in use.
My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated proxy-firewalled network. A quick look through XConfToolTask.java did not enlighten me. Any clues how to get the builds working again without requiring a network connection?
I wrote that overly verbose message for just such an occasion as this! The XConfToolTask (in tools/src/anttasks or used to be) was using a parser-specific setting to force it to not resolve dtd references. The line is:
builderFactory.setAttribute( "http://apache.org/xml/features/nonvalidating/load-external-dtd";,
new Boolean(false));
So, either the latest version of the XML libs committed recently by Antonio (this would be Xerces, no? I can never remember which X is which!) has changed this behavior, or something in the latest changes to support property expansion have broken it.
The first seems way more likely and may be documented at xml.apache.org in release notes. Unfortunately, don't have time to look into it myself.
Why would XConfToolTask be trying to go onto the network anyway? What DTD is it trying to get? Oh i see, it is trying to deal with web.xml which points to a DTD at Sun.
There is an attempt to use XMLCatalog in XConfToolTask. Perhaps we just need to add some configuration for a local copy. I vaguely recall investigating this before, but i think that i got frightened by Sun's conditions in the DTD license (the "not without written authorisation" thing).
http://marc.theaimsgroup.com/?t=105357989100002&r=1&w=2 is where we discussed the issues. I think (though I only scanned the archive this time) that we decided there _probably_ was a licensing issue (I could swear someone eventually chimed in more definitively but can't find it ATM) but that configuring to not resolve external DTD was enough for this use anyway. Now that's broken but it isn't clear why yet so discussing another solution is probably premature.
Can someone try rolling back Xerces to prior version to make sure that's the issue? Of course, you'll have to unplug from the network before building or you won't notice the issue. I looked briefly at Xerces' site last night and didn't find any clues this was intentionally changed in the latest release but there were some bugfix descriptions which could point to an accidental new problem.
Geoff
