Bug - GWT1.1.0 - Loading Jar file modules generated from Eclipse

134 views
Skip to first unread message

aglaforge

unread,
Aug 15, 2006, 10:55:32 AM8/15/06
to Google Web Toolkit
In the previous version of GWT 1.0.21 there was no problem exporting a
.jar file module out and using that in another project. However, in
upgrading to GWT1.1.0 I found that a jar file that worked with the
previous release no longer worked with 1.1.0. After a few hours...and
a night's rest... and a lot of trial and error... I found that the
problem had to with the file itself. If I went in and extracted the
jar file, and then immediately compressed the contents to a zip file
and then renamed the extension (using PowerArchiver.... free plug for a
good app) back to .jar everything worked fine again.

Had this not worked in GWT 1.0.21 I'd figure the error was on my end
and give up, however it would appear something has fundamentally
changed in the 1.1.0 release.

Scott Blum

unread,
Aug 15, 2006, 11:59:40 AM8/15/06
to Google Web Toolkit
Hi algaforge,

Do you still have a copy of the non-working version of the jar? I'd
like to take a look at it and see if I can figure out why it was
failing.

Scott

vlad

unread,
Aug 15, 2006, 12:02:22 PM8/15/06
to Google Web Toolkit
Thanks,
I had the same problem, and your solution helped.

vlad

unread,
Aug 15, 2006, 12:02:24 PM8/15/06
to Google Web Toolkit

aglaforge

unread,
Aug 15, 2006, 12:08:21 PM8/15/06
to Google Web Toolkit
Scott,

Yes, thanks for taking a peak. You can find both files at:

http://sourceforge.net/project/showfiles.php?group_id=169331&package_id=193178&release_id=425534

(GWT 1.1.0 Compat)
googleMaps1.1.10_GWT1.1.0_Compatible.jar 120585 0
Platform-Independent .jar

(GWT 1.0.21 Compat)
googleMaps1.1.10.jar 121647 61 Platform-Independent .jar

Cheers,

Anthony Laforge

sluramod

unread,
Aug 15, 2006, 12:59:33 PM8/15/06
to Google Web Toolkit
Everything works for me after I figured out how to do it properly:

1. export as a jar file from eclipse
2. check 'Add directory entries' checkbox

You guys need to hire more QA people.

Alexei

aglaforge

unread,
Aug 15, 2006, 2:28:08 PM8/15/06
to Google Web Toolkit
Alexei, excellent post, that does fix it. You're right, I was not
using the "Add directory entries" line. I guess what bothers me is
though is that the jar files we released previously worked with version
1.0.21 and then broke with 1.1.0, presumabley for that reason.

One thing I will say though is that I do wish I could get more QA
testers and developers for the GoogleMaps GWT widget project,
unfortunately it's a one man show at the moment and I could certainly
use the help (while it's under my mapitz.com domain, it's fundamentally
not a corporate sponsored project).

Cheers,

Anthony

Scott Blum

unread,
Aug 15, 2006, 3:11:39 PM8/15/06
to Google Web Toolkit
Yep, I was arriving at the same conclusion at the same time, it hinges
on directory entries being present. I'll try to explain why this
changed in 1.1.0.

In 1.0.21, when a module had a source entry or public entry, that would
be immediately resolved to an exact physical location. So if
googleMaps.gwt.xml sourced the client folder, that would become
something like:

jar:file:/path/googleMaps.jar!/com/mapitz/gwt/googleMaps/client/

We'd then inspect that particular URL path and find all the files under
it. Problem was, if you wanted to add another class into the
com.mapitz.gwt.googleMaps.client package somewhere else on your
classpath, it wouldn't work at all; the file just wouldn't be found and
you'd have to do a bunch of wacky module inheritance to get the desired
effect.

Now in 1.1.0 things are a little different. When a module has a source
or public entry, that becomes a logical package inclusion rather than a
physical package inclusion. So the URL doesn't immediately resolve to
a single location. Instead, the entire classpath is searched for any
instances of "com/mapitz/gwt/googleMaps/client/", which can resolve to
multiple physical URLs:

file://path/myProject/src/com/mapitz/gwt/googleMaps/client/
jar:file://path/googleMaps.jar!/com/mapitz/gwt/googleMaps/client/

Which works great and does what you would have expected it to do to
begin with. Problem is, if a jar is built without directory entries,
you literally cannot find "com/mapitz/gwt/googleMaps/client/" anywhere
on the classpath. It just isn't there. Perhaps there's a way to work
around this, but it seems to be a URLClassLoader/jar limitation.

Comments, ideas?
Scott

aglaforge

unread,
Aug 15, 2006, 5:34:52 PM8/15/06
to Google Web Toolkit
Scott,

I appreciate the depth of your feedback, that makes a lot of sense.
>From now on I'll make sure that little box is checked when I do an
export. Thinking out loud, I'd say that given the default eclipse
setting for exporting jar does not have that value set, it might be
helpful for future developers to have a document that explains the
requirements for exporting modules (perhaps a tip in there about
eclipse). Dunno, just a thought, but again many thanks for looking
into this.

Kind Regards,

Anthony

sluramod

unread,
Aug 15, 2006, 8:31:37 PM8/15/06
to Google Web Toolkit
Anthony,

I was referring to google gwt team when I said they need more qa.

Alexei

Rhyce

unread,
Aug 15, 2006, 11:16:54 PM8/15/06
to Google Web Toolkit
Idea for changing this:

One idea might be to ditch the gwt.xml files and use annotations,
instead. That way you could mark classes that can be compiled via the
GWT compiler.

@GWT
public class foo{

}

Then, have the compiler walk the classpath, looking for any .java
files. Might slow down the compiler a bit, but since most people won't
be linking GWT apps against jars with source, it might not be too bad.
Not sure if that helps at all. I'd have to think/know more about how
your classloader is actually doing its thing.

Best,
Rhyce

Scott Blum

unread,
Aug 16, 2006, 12:03:22 PM8/16/06
to Google Web Toolkit
The slowness would be a major issue. I'm not happy with the speed at
which hosted mode and compiles run, and indeed am wanted to make both
of those faster. Having no ability to filter out source would be a
step in the wrong direction, IMHO. Also, annotations aren't supported
until Java 5.0, so requiring them would force everyone to upgrade.

Scott

Ed Burnette

unread,
Aug 22, 2006, 10:29:27 PM8/22/06
to Google Web Toolkit
I read the first Java 7.0 downloads are available now so 5.0 is looking
old hat. :)

marsh...@gmail.com

unread,
Aug 29, 2006, 9:45:27 AM8/29/06
to Google Web Toolkit
So let me back up to something more basic because it isn't defined
explicitely anywhere and I'm struggling to get a compilation working.
(The above post says there is a need for more QA. What is needed is
better doc!)


I've built some java classes that are utilities useful for any GWT
modules I write. I've put them in the package gwtutils. The source
is in G:\MyGWTUtils\src\gwtutils. I have not defined them as a module
(should I?) as they are just some classes I'd like to use similar to a
jar file that one puts on a classpath.

Now I have an app with a GWT module defined somewhere else on E:\MyApp
(say) and I edit the MyApp.gwt.xml file so that it can use classes from
gwtutils. How do I do it?

Currently I'm doing this:

<module>

<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>
<source path="G:/MyGWTUtils/src"/>
<source path="client"/>

and getting errors like:

[ERROR] Line 4: The import gwtutil cannot be resolved

I've tried turning the slashes backward, adding the gwtutil folder
after src. Nothing works. I'm stuck.

thanks for any help.

dm

marsh...@gmail.com

unread,
Aug 29, 2006, 10:01:18 AM8/29/06
to Google Web Toolkit
Figured it out. Have to build a module for the util classes.

What I said about better doc still holds. As an example the RPC stuff
caused a lot of confusion in the first release. In this new (August)
release, I see absolutely no attempt to beef up the documentation. It
seems that Google is relying on the developer forum to be the
documentation for GWT

see:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/671d2eca099f3cc5/0d79561349c4d75e?lnk=gst&q=module+source+path&rnum=2#0d79561349c4d75e

Reply all
Reply to author
Forward
0 new messages