Steve Loughran wrote:
I would guess from this trace that there is a bad JAR file somewhere in
my (long, convoluted, m2-tasks created) classpath, something breaking
javac.
the problem of course is that javac isnt helpful enough to tell me which
file. I have tried unzipping everything, but of course, ant's <unzip>
task doesnt complain at all, and nor, apparently, does <jar> and <exec
executable="jar" />.
what else do I have to track this down?
compile:
[depend] The class
org.smartfrog.services.deployapi.transport.config.Axis2ServiceImpl_Stub
in file
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes/org/smartfrog/services/deployapi/transport/config/Axis2ServiceImpl_Stub.class
is out of date due to
org.smartfrog.services.deployapi.transport.config.Axis2Service but has
not been deleted because its source file could not be determined
[core:javac] Compiling 13 source files to
/home/slo/Projects/SmartFrog/Forge/core/components/deployapi/build/classes
[core:javac] java.lang.IndexOutOfBoundsException
[core:javac] at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
[core:javac] at
The corruption is caused by duplicate .class files in the JAR.
Fortunately it was one of my projects, and by changing the presetdef for
jar to default="preserve" and rebulding it went away. If the defect was
in a JAR file that I was autoloading from the network repositories, I
would have been stuffed.
Why dont we set default="preserve" rather than default="add" on the zip
tasks, on the basis that it may break BC, but it is probably a bug to
have this problem anyway?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
