Ant tasks ZipException

[birwin]

I have been trying to solve this problem all day and I cannot seem to
make any headway. My Ant task that compiles my GWT files is giving me
this exception over and over:

java.util.zip.ZipException: error in opening zip file

I am using Eclipse 3.4 (Ganymede) with Ant 1.7.0. My GWT Version is
1.5.

Here is the portion of the task that is supposed to compile the GWT
code:

<java classname="com.google.gwt.dev.GWTCompiler">
<arg value="-out" />
<arg file="web" />
<arg value="%*" />
<arg value="com.webapp.Timecard" />
<classpath>
<fileset dir="src" />
<path refid="compile.cp" />
<path refid="class.path" />
<path refid="gwt.path" />
</classpath>
</java>

My log file has thousands of the following error messages:

Ignoring Exception java.util.zip.ZipException: error in opening zip
file reading resource com/google/gwt/dev/GWTCompiler.class from C:
\Documents and Settings\fred\workspace\com\webapp\Timecard.gwt.xml

(Each message is exactly the same except that the file name is
different. Each of my "Java" and "PNG" files are listed)

Then this stack trace is displayed in my log file over and over again:

[java] java.util.zip.ZipException: error in opening zip file
[java] at java.util.zip.ZipFile.open(Native Method)
[java] at java.util.zip.ZipFile.<init>(ZipFile.java:203)
[java] at java.util.zip.ZipFile.<init>(ZipFile.java:234)
[java] at
org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:
1014)
[java] at
org.apache.tools.ant.AntClassLoader.getResource(AntClassLoader.java:
917)
[java] at
com.google.gwt.util.tools.Utility.computeInstallationPath(Utility.java:
283)
[java] at
com.google.gwt.util.tools.Utility.getInstallPath(Utility.java:224)
[java] at
com.google.gwt.util.tools.ToolBase.<clinit>(ToolBase.java:55)
[java] at java.lang.Class.forName0(Native Method)
[java] at java.lang.Class.forName(Class.java:242)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:
135)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:747)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:201)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:
104)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[java] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown
Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:
105)
[java] at org.apache.tools.ant.Task.perform(Task.java:348)
[java] at org.apache.tools.ant.Target.execute(Target.java:357)
[java] at org.apache.tools.ant.Target.performTasks(Target.java:
385)
[java] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[java] at
org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[java] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:
41)
[java] at
org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:
32)
[java] at
org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[java] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:
423)
[java] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:
137)

[Isaac Truett]

It appears that you are putting individual files in your classpath instead of directories. Ant tries to open each of those files expecting them to be zip files.

Change your classpath so that it points to the root of your source and class file trees, not each file in those trees. The only non-directory entries in your classpath should be jar files.

[birwin]

Thank You Isaac,

That did eliminate the ZipException...

I am now getting this error. From what I can tell, this indicates my
classpath does not include my client source files.

[java] Loading module 'com.sosstaffing.soar.webapp.Timecard'
[java] Translatable source found in...
[java] [WARN] No source path entries; expect subsequent
failures
[java] com.google.gwt.core.ext.typeinfo.NotFoundException:
java.lang.Object

My GWT Compile task now looks like this:

<java classname="com.google.gwt.dev.GWTCompiler">
<arg value="-out" />
<arg file="web" />
<arg value="%*" />
<arg value="com.webapp.Timecard" />
<classpath>

<pathelement location="${dir.src}" />

<path refid="compile.cp" />
<path refid="class.path" />
<path refid="gwt.path" />
</classpath>
</java>

I am assuming this error means that the GWT compiler still cannot find
my source files. The ${dir.src} in my pathelement tag is the location
of my source files (the src directory that contains my com folder) My
Timecard.gwt.xml file is located in the com.webapp folder and my
client source files are located in com.webapp.client folder.


Here is my file structure:

+src
+com
+webapp
+client
Timecard.gwt.xml


This looks right to me, but I am new to GWT and must be missing
something.

On Oct 11, 6:35 am, "Isaac Truett" <itru...@gmail.com> wrote:
> It appears that you are putting individual files in your classpath instead
> of directories. Ant tries to open each of those files expecting them to be
> zip files.
> Change your classpath so that it points to the root of your source and class
> file trees, not each file in those trees. The only non-directory entries in
> your classpath should be jar files.
>

[Isaac Truett]

> [java] com.google.gwt.core.ext.typeinfo.NotFoundException:
> java.lang.Object

This suggests to me that you don't have gwt-user.jar on your classpath.

[birwin]

Thanks again for your response Isaac,

I believe I do have the gwt-user.jar on my path... I am using Ivy for
my dependency resolution. I assigned the gwt JARs from IVY and named
the path "gwt.path"

Just to make sure the user JAR was on the path, I assigned the path to
a property and then echoed the property to System.out. Here is the ant
calls I made and the subsequent message printed to System.out:


<property name="gwt.path.property" refid="gwt.path" />
<echo message="classpath= ${gwt.path.property}"/>

[echo] classpath= C:\Documents and Settings\irwinb\.ivy2\cache
\com.google\gwt-dev-windows\jars\gwt-dev-windows-1.5.0.jar;C:
\Documents and Settings\irwinb\.ivy2\cache\com.google\gwt-user\jars
\gwt-user-1.5.0.jar

You can see that gwt.path apears to hold gwt-user.jar (Version 1.5).

Assembling this path is controlled by an Ivy task, so I don't know the
details of how Ivy assembles classpaths, but I did verify the JAR was
in the location specified.

Any other ideas or did I miss something?

- Brian I.

On Oct 13, 10:38 am, "Isaac Truett" <itru...@gmail.com> wrote:
> >     [java] com.google.gwt.core.ext.typeinfo.NotFoundException:
> > java.lang.Object
>
> This suggests to me that you don't have gwt-user.jar on your classpath.
>

[Isaac Truett]

You're right, it does appear to be there. Off the top of my head, I
can't think of what else would prevent the compiler from finding
java.lang.Object. I guess I'd want to look at Timecard.gwt.xml next,
just to see if something looks off. Would you mind posting that?

[birwin]

Sorry, the last Timecard.gwt.xml was not the correct one. Here is the
one I am using:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<module>

<!-- Inherit the core Web Toolkit stuff. -->
<inherits name="com.google.gwt.user.User"/>

<!-- Inherit Web Toolkit Incubator stuff -->
<inherits name="com.google.gwt.widgetideas.WidgetIdeas"/>
<inherits name="com.google.gwt.libideas.LibIdeas"/>

<!-- Specify the app entry point class. -->
<entry-point class="com.webapp.client.Timecard" />

<source path="client" />
<public path="public" />

<servlet class="com.webapp.server.TimecardServiceImpl" path="/
timecardservice" />
</module>

Thanks,

Brian I.

On Oct 13, 11:32 am, "Isaac Truett" <itru...@gmail.com> wrote:
> You're right, it does appear to be there. Off the top of my head, I
> can't think of what else would prevent the compiler from finding
> java.lang.Object. I guess I'd want to look at Timecard.gwt.xml next,
> just to see if something looks off. Would you mind posting that?
>

[Isaac Truett]

That looks fine to me. I'm really fishing now... could you open up
gwt-user.jar and confirm that it contains
com/google/gwt/emul/java/lang/Object.java?

[birwin]

It does contain com/google/gwt/emul/java/lang/Object.java

Just to make sure the GWTCompile task handles spaces in its classpath,
I moved the user.jar to the root directory and created a new classpath
that just had that JAR. I tried a recompile and included the new
classpath and again it failed with the same error.

I believe I am going to start from scratch and try to do a "Hello
World"-type build where I don't include any Ivy dependencies, etc...
and everything is very basic.

Once I have that working, I will return to debugging this build. If I
find a solution, I will post it here when I finish.

Thank you for your help I appreciate it.

- Brian I.

On Oct 13, 12:03 pm, "Isaac Truett" <itru...@gmail.com> wrote:
> That looks fine to me. I'm really fishing now... could you open up
> gwt-user.jar and confirm that it contains
> com/google/gwt/emul/java/lang/Object.java?
>

> >> >> >> > org.apache.tools.ant.Project.executeTargets(Project.java:1181)...
>
> read more »

[Isaac Truett]

Sorry I couldn't identify the exact problem. It certainly is an odd
error. The only other time I've seen it fail to find java.lang.Object
was in this thread:

http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/7b2b7db63bbccdd6/fd3e1e17082d2f66?#fd3e1e17082d2f66

... where I solved the problem by dumping my classpath and starting
from scratch, basically.
I never did find exactly what was causing the problem, but hopefully
starting from scratch will work for you, too.

[birwin]

Well,

I have created from scratch the simplest GWT application I could think
of... I created the simplest build file I could think of (No Ivy
dependency management, no code... Just a blank web page) and then
attempted to build the project... I got exactly the same results as
above.

I decided to try a different version of Ant just to ensure it had
nothing to do with Ant, and again the same results.

I am not sure what to do at this point. I may try the build on another
machine just to make sure it is not my environment. I may have to rely
on a non-ant build (Cypal Studio in Eclipse) which seems to work
without any problems. Unfortunately, there is no way to automate that
process.

- Brian I.

On Oct 13, 12:24 pm, "Isaac Truett" <itru...@gmail.com> wrote:
> Sorry I couldn't identify the exact problem. It certainly is an odd
> error. The only other time I've seen it fail to find java.lang.Object
> was in this thread:
>

> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...

>
> ... where I solved the problem by dumping my classpath and starting
> from scratch, basically.
>  I never did find exactly what was causing the problem, but hopefully
> starting from scratch will work for you, too.
>

> >> >> >> >> >     [java]     at...
>
> read more »

[Isaac Truett]

> <path refid="compile.cp" />
> <path refid="class.path" />

What's in these? Are they also in your stripped-down build?

[walden]

Hi Guys,

Not sure if this could be related, but your ant target that uses the
<java> task to run the GWT compile needs to set fork=true. This takes
the ant classloader out of the equation. As I recall, the ant
classloader defeates GWT; I don't remember the specifics.

Walden

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

[birwin]

Walden,

When I place fork=true in the java tasks, it compiles correctly. I had
to adjust the memory as I ran out of memory during the build, but it
appears to work fine now. I appreciate the input. I tried to look on
the Internet to find more information regarding why the GWTCompiler
run in a java Ant task needs fork=true, but I could find no
information.

It works anyway, even if I don't understand why, so I will move on...
Thank you Walden and thank you Isaac for your time and help.

- Brian I.

> > >> >> >> >> >> >                <java...
>
> read more »

[walden]

Yeah, I lost a lot of time on this a year and a half ago when I was
trying to revive someone's GWT compile ant task code which was
apparently written for GWT 1.3 or earlier. I've forgotten the
specifics now, but it has to do with the search order used by the
different loaders (I think). Anyway, I was wondering whether it would
make sense to write an issue against this. Would it be feasible for
the GWT compiler to examine its context classloader (or whatever it
uses to find GWT resources) and fail fast if it's the wrong one? This
problem may not be too common, but when it occurs, it tends to
dumbfound us for a while.

Walden

[Isaac Truett]

I'm not sure that the classloader's type would be a reliable check. Is there a practical way of knowing if any given classloader would be compatible? Just giving up if you don't find one specific classloader would cause GWTCompiler to fail in any environment that replaced that classloader, even with a compatible substitute.

What I can suggest is a GwtCompilerTask for Ant that I've started working on in the Incubator.
It's very much an alpha version, but it works in my tests and handles forking automatically. You can find it in the Incubator trunk and I also did a quick write-up about it yesterday. Feedback is very much appreciated.

[walden]

Isaac,

Since the GWT compiler has specific needs pertaining to classloading,
I think it's appropriate to try to manage the problem internal to the
compiler. I have not looked at this in detail for a long time, so I
was wondering if anybody on the list was more conversant with how this
works. Your points are well taken. Maybe a warning rather than an
outright fail would be better. Just something so people don't keep
getting stuck in this particular bit of tar (I noticed another
incidence of this on the list yesterday).

The custom ant task is a fine idea, but its failing is that not
everyone will use it, and we're right back here.

Walden

On Oct 15, 8:17 am, "Isaac Truett" <itru...@gmail.com> wrote:
> I'm not sure that the classloader's type would be a reliable check. Is there
> a practical way of knowing if any given classloader would be compatible?
> Just giving up if you don't find one specific classloader would cause
> GWTCompiler to fail in any environment that replaced that classloader, even
> with a compatible substitute.
> What I can suggest is a GwtCompilerTask for Ant that I've started working on
> in the Incubator.
> It's very much an alpha version, but it works in my tests and handles
> forking automatically. You can find it in the Incubator trunk and I also did

> a quick write-up<http://publicint.blogspot.com/2008/10/introducing-gwtcompilertask.html>about