You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Antoine Lévy-Lambert <an...@antbuild.com> on 2003/12/06 13:01:47 UTC
AW: Suggestion for behavior change of (duplicate attribute ) WAS: Very odd issue with jar task
Hi Daniel,
thanks for reporting this problem. I agree with you that the default should
to be changed to "preserve", so that only users who know what they are doing
would be using the "add" option.
Let's see what other users and committers think about this issue.
Antoine
-----Ursprüngliche Nachricht-----
Von: Armbrust, Daniel C. [mailto:Armbrust.Daniel@mayo.edu]
Gesendet: Freitag, 5. Dezember 2003 23:51
An: 'Ant Users List'
Betreff: Suggestion for behavior change of <jar> WAS: Very odd issue
with jar task
I finally figured this out... The problem was happening because I had a jar
file with duplicate class files in it.
It turns out that javac will puke when it tries to load a class from a jar
file that exists in the jar file twice.
I filed a bug report with sun... They definitely shouldn't throw an
indexOutOfBounds exception when this occurs.
I also think there is something that should be changed in ant - this is what
caused me to get two class files in the jar file anyway.
The <jar> task has an optional argument of duplicate that takes the values
"add", "preserve" or "fail".
It defaults to "add".
Since the default can result in jar files that no java compiler can read, I
think that the default should be changed to "preserve".
Should I open a bug report, or should we just discuss this minor change
here?
Thanks,
Dan
-----Original Message-----
From: Armbrust, Daniel C. [mailto:Armbrust.Daniel@mayo.edu]
Sent: Friday, December 05, 2003 1:51 PM
To: 'user@ant.apache.org'
Subject: Very odd issue with jar task
I have a very frustrating problem that I hope someone may be able to shed a
bit of light on.... Sorry for the lengthy post, but I wanted to get all the
details out here.
I am building a jar file which contains my compiled source files, and the
contents of several other jar files, with a task like this:
<jar jarfile="${implAndDepend.jar}" basedir="${impl.target.dir}"
includes="**/*.class">
<zipgroupfileset refid="packageJars"/>
<zipgroupfileset refid="axisJars"/>
<zipgroupfileset dir="">
<include name="${wsdlJava.jar}"/>
</zipgroupfileset>
</jar>
Those refid's are defined like this:
<path id="allJars">
<fileset dir="${externalLib.dir}" id="packageJars">
<include name="log4j-1.2.6.jar"/>
<include name="gnu-regexp-1.1.4.jar"/>
<include name="castor-0.9.4.jar"/>
<include name="castor-0.9.4-xml.jar"/>
<include name="jdbc-se2.0.jar"/>
<include name="jta1.0.1.jar"/>
<include name="allToolsModified.jar"/>
<include name="pgjdbc2.jar"/>
</fileset>
<fileset dir="${externalLib.dir}/axis/" id="axisJars">
<include name="**/*.jar"/>
</fileset>
</path>
This works fine, I end up with one big jar file. I have done this for
several months without an issue. The resulting jar file works fine when
used as a runtime library.
Now, I have another project that depends on this library.
My compile task in that project looks like this:
<javac srcdir="${src}" destdir="${classes}">
<classpath path="${extLib}/implAndDepend.jar"/>
</javac>
This has worked fine up until yesterday. Now, when I run compile, I get
this exception:
Buildfile: D:\Eclipse Projects\general-workspace\ctsbackend\build.xml
init:
[mkdir] Created dir: D:\Eclipse
Projects\general-workspace\ctsbackend\antBuild
compile:
[mkdir] Created dir: D:\Eclipse
Projects\general-workspace\ctsbackend\antBuild\classes
[javac] Compiling 8 source files to D:\Eclipse
Projects\general-workspace\ctsbackend\antBuild\classes
[javac] An exception has occurred in the compiler (1.4.2_02). Please
file a bug at the Java Developer Connection
(http://java.sun.com/cgi-bin/bugreport.cgi) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in your
report. Thank you.
[javac] java.lang.IndexOutOfBoundsException
[javac] at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1085)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.complete(ClassReader.java:1046)
[javac] at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:332)
[javac] at
com.sun.tools.javac.v8.code.Symbol$ClassSymbol.complete(Symbol.java:651)
[javac] at
com.sun.tools.javac.v8.code.ClassReader.loadClass(ClassReader.java:1113)
[javac] at
com.sun.tools.javac.v8.comp.Resolve.loadClass(Resolve.java:485)
[javac] at
com.sun.tools.javac.v8.comp.Resolve.findIdentInPackage(Resolve.java:660)
[javac] at com.sun.tools.javac.v8.comp.Attr.selectSym(Attr.java:1140)
[javac] at com.sun.tools.javac.v8.comp.Attr.visitSelect(Attr.java:1089)
[javac] at
com.sun.tools.javac.v8.tree.Tree$Select.accept(Tree.java:1091)
[javac] at com.sun.tools.javac.v8.comp.Attr.attribTree(Attr.java:256)
[javac] at com.sun.tools.javac.v8.comp.Attr.attribType(Attr.java:286)
[javac] at
com.sun.tools.javac.v8.comp.Enter$MemberEnter.visitImport(Enter.java:754)
[javac] at com.sun.tools.javac.v8.tree.Tree$Import.accept(Tree.java:407)
[javac] at
com.sun.tools.javac.v8.comp.Enter$MemberEnter.memberEnter(Enter.java:707)
[javac] at
com.sun.tools.javac.v8.comp.Enter$MemberEnter.memberEnter(Enter.java:719)
[javac] at
com.sun.tools.javac.v8.comp.Enter$MemberEnter.visitTopLevel(Enter.java:738)
[javac] at
com.sun.tools.javac.v8.tree.Tree$TopLevel.accept(Tree.java:390)
[javac] at
com.sun.tools.javac.v8.comp.Enter$MemberEnter.memberEnter(Enter.java:707)
[javac] at
com.sun.tools.javac.v8.comp.Enter$CompleteEnter.complete(Enter.java:833)
[javac] at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:332)
[javac] at
com.sun.tools.javac.v8.code.Symbol$ClassSymbol.complete(Symbol.java:651)
[javac] at com.sun.tools.javac.v8.comp.Enter.complete(Enter.java:593)
[javac] at com.sun.tools.javac.v8.comp.Enter.main(Enter.java:574)
[javac] at
com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:334)
[javac] at com.sun.tools.javac.v8.Main.compile(Main.java:520)
[javac] at com.sun.tools.javac.Main.compile(Main.java:36)
[javac] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javac] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
[javac] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
[javac] at java.lang.reflect.Method.invoke(Method.java:324)
[javac] at
org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:100)
[javac] at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)
[javac] at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
[javac] at org.apache.tools.ant.Task.perform(Task.java:341)
[javac] at org.apache.tools.ant.Target.execute(Target.java:309)
[javac] at org.apache.tools.ant.Target.performTasks(Target.java:336)
[javac] at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
[javac] at
org.apache.tools.ant.Project.executeTargets(Project.java:1255)
[javac] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunn
er.java:379)
[javac] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRun
ner.java:166)
BUILD FAILED: file:D:/Eclipse
Projects/general-workspace/ctsbackend/build.xml:38: Compile failed; see the
compiler error output for details.
Total time: 891 milliseconds
I can't figure out what I changed between yesterday and today to make this
occur. Here are some additional oddities:
If I use the <unjar> task to unjar implAndDepend.jar into a temp folder, and
then point the <javac> task to that folder for the classpath, everything
works fine.
If I manually (using winzip) unzip the file implAndDepend.jar, and then
rezip it with winzip, everything works fine.
If I execute jar -tf implAndDepend.jar it lists all the classes in the jar
file without any issues.
What could possibly be wrong with this jar file that is causing this
exception?
Thanks
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Suggestion for behavior change of (duplicate attribute ) WAS: Very odd issue with jar task
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 6 Dec 2003, Antoine Lévy-Lambert <an...@antbuild.com> wrote:
> I agree with you that the default should to be changed to
> "preserve", so that only users who know what they are doing would be
> using the "add" option.
I agree it would be the "correct" default value for <jar> (and <war>
and <ear>) - but don't think we can change it for backwards
compatibility reasons.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org