Remove or change timestamp of javax.servlet source files in gwt-user.jar

[dankurka]

Originally reported on Google Code with ID 3439

Found in GWT Release:
1.6.0

Detailed description:
The 1.6.0 and 1.6.1 versions of gwt-user.jar contain the
source code for the javax.servlet package.
The problem is the source code has a newer timestamp than the class files.
This causes the javax.servlet classes to be recompiled by maven and placed
in the war's WEB-INF/classes directory.
These classes then conflict with the provided servlet-api.jar found in most
application servers.

Can someone fix the deployed jars to either:
1) include class files having a later timestamp than the source files
or
2) contain no javax source code.

The source code might not be required, since the jars for version 1.5.3
didn't include any javax.servlet sources.

(this description was adapted from Will's post explaining the problem in
the gwt group)

Workaround if you have one:
(I use linux)
What worked for me was to update all the timestamps in the jar's
javax.servlet package to the same date as the GWT 1.5.3's classes
timestamps. I then deployed them to my local maven repository, under a new
version "1.6.1-patched".

Script to change timestamps :

---------------------
#!/bin/bash
#

PATH_TO_GWT_USER_JAR=$1

mkdir work
cd work
cp -v $PATH_TO_GWT_USER_JAR .
jar xf gwt-user-1.6.1.jar javax/servlet
touch -mt 200408280906 javax/servlet/*
touch -mt 200408280906 javax/servlet/**/*
jar uf gwt-user-1.6.1.jar javax/servlet/
-------------------------------

You need to tell the script what jar it should modify:
patchGwtJavaxServlet.sh
/home/username/.m2/repository/com/google/gwt/gwt-user/1.6.1/gwt-user-1.6.1.jar

You will then have a /work directory containing gwt-user-1.6.1.jar with
corrected timestamps. You then need to put it on your local repository or
company repository following the standard maven practice, and to update
your pom.xml to use this patched jar.

Links to the relevant GWT Developer Forum posts:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/e0486a1de1f58c06/00bfe80aac3408e6

Reported by neveue on 2009-03-04 12:40:26

[dankurka]

Seems like an easy fix that will have a lot of benefit for Maven users. Sending over

to Scott for a deeper look.

Reported by sumitchandel+legacy@google.com on 2009-03-06 23:17:48

• Labels added: Category-Build, Type-Defect, Priority-High

[dankurka]

Fixed in r4951.

Reported by scottb+legacy@google.com on 2009-03-07 00:49:51

• Status changed: FixedNotReleased
• Labels added: Milestone-1_6_RC

[dankurka]

still the same bug in the 1.6.4 release !!

Reported by cyril.lakech on 2009-04-23 21:14:35

[dankurka]

1_6_RC has been released.

Reported by jlabanca+personal@google.com on 2009-05-11 19:55:04

• Status changed: Fixed

[dankurka]

@Cyril (Comment 4):
I'm using the 1.6.4 release since a few weeks and it works flawlessly for me. I think
the bug was fixed.

------ Details --------
I checked the timestamps in the gwt-user-1.6.4.jar, and the javax/servlet/*
filestamps are indeed correct:
- the .class files all have the modified timestamp: 2008-07-22 02:00:30.000000000 +0200
- the .java files all have the modified timestamp: 2008-07-22 02:00:00.000000000 +0200
Since the .class files have a more recent timestamp than the .java files, the bug we
had in 1.6.1 does not occur anymore.
----End of Details-----

@gwt-team:
While commenting, I'd also like to thank you for fixing this bug. I didn't do it
before because I wanted to avoid spamming the Issue Tracker to simply say "Thanks".
So:
Thanks for fixing this bug promptly and thanks for the great work you do on GWT!

Reported by neveue on 2009-05-14 09:15:50

[dankurka]

Yes the timestamps problem is fixed. Great ! 

But we still have to filter our compilation because of the java files in this jar...
the compilation of our project compile also the javax servlet java files in our
output dir and in our war... so we got errors at runtime because javax servlet are
already on the application server.

Any idea ? Why do we need those java files in this jar ? in 1.5.3 we did not have
this issue...

Reported by cyril.lakech on 2009-05-14 09:23:05

[dankurka]

I would say there's a problem with your tooling if you have a tool that insists on 
recompiling Java files that are in a jar, particularly when the class files are 
already up-to-date.

The source if provided as a convenience for debugging.

Reported by scottb+legacy@google.com on 2009-05-14 16:28:15

[dankurka]

I use maven 2 and the gwt maven plugin from codehaus...

Sources should be in another artifact I think, he we want to debug google code we
could add this sources distribution to the classpath... (a gwt-users-sources.jar as
maven does...)

I know that you don't use maven 2 but my context is a very popular enterprise context.

You should have a closer look to this issue. Maybe the solution is just to remove
java files from the jar and change your mind about distribution of the gwt libraries.

Thanks

Reported by cyril.lakech on 2009-05-14 16:37:05

[dankurka]

I can confirm that maven insists in compiling the sources for the javax.servlet
package so this is still somewhat of an issue (can be worked around with other maven
plugins but it still is a PITA)

Scott, you say that those java files are provided as a convenience for debugging and
I understand the logic behind that argument but, are you sure that gwt devs would
really go so far as to place break points in javax.servlet.* classes ? Why would they
do that ? (I honestly can't think of any use case where this would be needed)

Reported by diaz.salvador on 2009-06-15 11:19:07

[dankurka]

Nobody should need to debug javax.servlet as we never need to debug spring, hibernate
or other frameworks internal code...

By convention, a product (like gwt-user) should be provided without the sources in
a
bundle and optionalty with sources in another bundle.

This standrd is not only a maven standard but a best pratice in general. On many
project, you can find a product.zip and a product.src.zip on the download page for
sample.

Maybe there is a problem with my tooling (Eclipse + Maven) and every solution is welcome.

Reported by cyril.lakech on 2009-06-15 12:22:19