Packaging error in gwt-user 1.6.4 with javax servlet classes and java files

27 views
Skip to first unread message

cyril.lakech

unread,
Apr 24, 2009, 3:51:14 AM4/24/09
to Google Web Toolkit
Hi,

There is an error in GWT 1.6.4 release distribution. Because of a bad
packaging of the product, there are too much files in the jar. The
javax/servlet classes are in the jar and the java files too. And when
you compile you GWT application, these java files are compiled and gwt
put them in the classes package of the output directory. So the javax/
servlet classes are in the war of the project and all the applications
servers embedded this library already.
So we got a wonderfull linkage error at runtime.

This issue was already discussed here =>
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/e0486a1de1f58c06/d22b7bc2d0b63e1e?lnk=raot

And there is an open and fixed issue here :
http://code.google.com/p/google-web-toolkit/issues/detail?id=3439

But this fix was not release.

There is a workaround : remove all the java files from javax/servlet
of the gwt-user.jar and change all the timestamps of the class file to
a very old date (2004)

When this issue will be fixed in the distribution of gwt-user ?

Bst rgds,

Isaac Truett

unread,
Apr 24, 2009, 10:21:48 AM4/24/09
to Google-We...@googlegroups.com
Works fine for me. Why are you even compiling those classes?

Jason Essington

unread,
Apr 24, 2009, 10:44:20 AM4/24/09
to Google-We...@googlegroups.com
Two things,

First, you should be excluding anything in a **/client/** package from
your java compile, as that stuff doesn't need to be compiled for the
server.
Second, you shouldn't ever deploy the gwt-user.jar to your server,
that is what the gwt-servlet.jar is for. gwt-user.jar is strictly for
use by the GWT compiler (it requires source files) and development
(which requires the servlet interfaces).

-jason

Scott Blum

unread,
Apr 24, 2009, 12:11:42 PM4/24/09
to Google-We...@googlegroups.com
I don't see this in 1.6.4.  As far as I can tell, all of the .java files in javax/servlet have a timestamp of:

Tue Jul 22 02:00:00 EDT 2008

All of the .class files have:

Tue Jul 22 02:00:30 EDT 2008

The class files are 30 seconds newer than the source files.

cyril.lakech

unread,
Apr 24, 2009, 7:53:38 PM4/24/09
to Google Web Toolkit
OK, thank you very much for your answers !

@Isaac: I don't know why, these classes just appears in my war ! I
come here to understand.
@Jason: 1st/ OK that is done but that does not solve my problem. 2nd/
the gwt-user library is never deploy because of the provided scope of
the maven config for this dependency.
@Scott: Good news ! But when I remove the java files, I do not have
any problem... any idea ?

So what can I do to remove those javax/servlet files from my war under
classes directory ?

I just got gwt-user in scope provided (I use maven and the gwt-maven-
plugin from codehaus) and then the gwt compilation add the javax/
servlet class files in my output classes directory and my war...

Bst rgds,

cyril.lakech

unread,
Apr 25, 2009, 7:11:01 AM4/25/09
to Google Web Toolkit
I add an exclude to my compiler but that does not change anything

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
<excludes>
<exclude>javax/servlet/**</exclude>
</excludes>
</configuration>
</plugin>

I don't understand why this javax classes are in the war...

I would like not to add a ant run task to remove those file from the
compiled classes directory.

cyril.lakech

unread,
Apr 25, 2009, 9:52:42 AM4/25/09
to Google Web Toolkit
I manage to remove the javax directory from the war with the maven-
antrun-plugin and the delete ant task :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>remove-javax</id>
<phase>compile</phase>
<configuration>
<tasks>
<delete dir="${project.build.directory}/classes/javax" />
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>

A better solution would be welcome...
Reply all
Reply to author
Forward
0 new messages