ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <anto...@gmx.de>
Subject Re: corrupt jar files and javac
Date Fri, 16 Sep 2005 16:56:22 GMT
Hello Steve,
I am working in an environment where all makes are done with
"duplicates=preserve". Now I think such a change does break BC.
BC is a huge advantage of ant. Where I am working, a lot of makes have
been switched from Ant 1.4 to Ant 1.6 with only 2 tiny problems,
which were a different behavior for "user properties" ( ant
-D"someprop=value") and one protected method of the Zip task which had
changed signature.

Cheers from Frankfurt,

Antoine

Steve Loughran wrote:

> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message