Error when using modules that has to be set in the classpath before the gwt-user.jar (in this case GWTx)

[GoogleCodeExporter]

Is this Maven 1 or Maven 2?
Maven 2

What steps will reproduce the problem?
1. Inheritance of the GWTx module by following lines in the configuration
gwt.xml file:
<inherits name='com.googlecode.gwtx.Java'/>
<inherits name='com.google.gwt.user.User'/>
2. Starting the project with mvn gwt:gwt
Error output can be see in the maven and the gwt debug console!

What is the expected output? What do you see instead?
Excepted output is no Error message, instead i see following:
[ERROR] Errors in
'jar:file:/C:/Users/*****/.m2/repository/com/googlecode/gwtx/GWTx/20070605/GWTx-
20070605.jar!/com/googlecode/gwtx/java/io/emul/java/io/ByteArrayOutputStream.jav
a'
      [ERROR] Line 81:  The method close() is undefined for the type
OutputStream
      [ERROR] Line 256:  The method write(byte[], int, int) is undefined
for the type OutputStream

What version of the product are you using? On what operating system?
gwt-maven 2.0 beta13 with maven 2.0.9 on Windows Vista SP1

Please provide any additional information below.
Problem can be solved by setting the GWTx module in classpath before the
gwt-user.jar. It has to be possible to set any module before the
gwt-user.jar when nessassary.
A problem discription can also be found in the following thread:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/66ab00f55
0dc3976/0abc5059ed9fd0e0?#0abc5059ed9fd0e0
Using the new maven 2.0.9 version that sorts the classpath by dependency
order doesn't solve the problem! 

Original issue reported on code.google.com by mlegenha...@gmail.com on 21 Apr 2008 at 11:57

[GoogleCodeExporter]

First off, I don't think this is actually an error.  Yes, it's annoying to see 
this
on the console, and yes changing the classpath order would fix it - but it 
doesn't
seem to cause any actual problems when it occurs - the shell still works, and 
WARs
still work - in my experience (unless you are actually using 
ByteArrayOutputStream in
your client code - which is highly unlikely). 

Second, we had various issues trying to address this before.  Maybe we can now 
that
we are writing the classpath script ourselves - but previously we could not 
control
the order in M2 (wasn't us, just in general in M2 you can't control the order, 
if I
recall correctly).

We should look at this again, yes, but it's a low priority, because I don't 
think it
really causes any problems (please advise if I am wrong). 

Original comment by charlie....@gmail.com on 24 Apr 2008 at 3:38

[GoogleCodeExporter]

I don't worked yet with the GWTx module. But I work in environments where every
warning is a problem for the quality of the code.

I tryed a little bit and found a solution. With the new maven 2.0.9 it is 
possible to
sort the classpath be the dependency order. Look at following release note:
"MNG-1412 / MNG-3111 introduced deterministic ordering of dependencies on the
classpath. In the past, natural set ordering was used and this lead to odd 
results.
The ordering is now preserved from your pom, with dependencies added by 
inheritence
added last. In builds that had conflicting or duplicate dependencies, this may
introduce a change to the output. In short, if you have weird issues with 
2.0.9, take
a look at the dependencies to see if you have conflicts somewhere."

I see you are adding automatically the gwt-user.jar to the CLASSPATH. If I add 
the
gwt-user.jar to the dependencies in the pom.xml and delete the first 
gwt-user.jar
from the CLASSPATH generated by the gwt-maven-plugin, I can use the GWTx module
without ERROR.

My dependencies in the pom.xml looks like this:
<dependency>
   <groupId>com.googlecode.gwtx</groupId>
   <artifactId>GWTx</artifactId>
   <version>20070605</version>
</dependency>
<dependency>
   <groupId>com.google.gwt</groupId>
   <artifactId>gwt-user</artifactId>
   <version>1.4.62</version>
</dependency>
My modified execution command looks like this:
"C:\Program Files\Java\jdk1.6.0_05\jre\bin\java" -Xmx512M -cp
"D:\Dokumente\Programmieren\GWT\docma\src\main\resources";"D:\Dokumente\Programm
ieren\GWT\docma\target\gwtBin\gwt-windows-1.4.62";"D:\Dokumente\Programmieren\GW
T\docma\target\gwtBin\gwt-windows-1.4.62\gwt-dev-windows.jar";"D:\Dokumente\Prog
rammieren\GWT\docma\src\main\java";"D:\Dokumente\Programmieren\GWT\docma\classes
";"D:\Dokumente\Programmieren\GWT\docma\target\classes";"C:\Users\Malte\.m2\repo
sitory\com\googlecode\gwtx\GWTx\20070605\GWTx-20070605.jar";"C:\Users\Malte\.m2\
repository\com\google\gwt\gwt-user\1.4.62\gwt-user-1.4.62.jar";"C:\Users\Malte\.
m2\repository\com\google\gwt\gwt-servlet\1.4.62\gwt-servlet-1.4.62.jar";
-Dcatalina.base="D:\Dokumente\Programmieren\GWT\docma\target\tomcat" 
com.google.gwt.dev.GWTShell -gen
"D:\Dokumente\Programmieren\GWT\docma\target\.generated" -logLevel INFO -style 
OBF
-out "D:\Dokumente\Programmieren\GWT\docma\target\docma" -port 8888
de.bamannheim.docma.Application/Application.jsp

So maybe it would be a solution if you don't add the gwt-user.jar (by an 
gwt-maven
plugin option) automatically to the classpath and add the dependency to the 
pom.xml.

P.S. Sorry for the german classpath ;)

Original comment by mlegenha...@gmail.com on 24 Apr 2008 at 10:16

[GoogleCodeExporter]

We have to add gwt-user to the classpath for GWTTestCase based tests and a few 
other
hoops - we tried not adding it manually in the past, ran into other problems. 
Though, nice to know that with 2.0.9 we can order deps - thanks for that tip.  
Maybe
we can re-think/re-work things now (agreed it's a problem, we would rather NOT 
add it
manually, but again had to in the past). 

Original comment by charlie....@gmail.com on 13 May 2008 at 1:15

[GoogleCodeExporter]

I'm facing a somewhat similar problem, I need to configure the order of the 
classpath. 
Basically I need that my project resources apear before the gwt-* jar's in the 
classpath.
Is there a way to configure this?
The current work arround was to modify the order of the classpath is 
constructed in
AbstractGWTMojo

The patch sshowing the changes is attached.

Regards

Original comment by guillo.g...@gmail.com on 14 May 2008 at 10:16

Attachments:

• AbstractGWTMojo.java.patch

[GoogleCodeExporter]

I need to replace one of the classes defined in gwt-user.jar with one of my 
own. This
basically puts me in the same position as guillo.gonzo, and his patch will also 
solve
my problem.

Please at least give us the option to have the gwt jars at the end of the 
classpath
instead of at the beginning. Perhaps they should just always be at the end of 
the
classpath (as in his patch).

Original comment by kind...@gmail.com on 4 Sep 2008 at 11:38

[GoogleCodeExporter]

I found another work-around: give a fake path for google.webtoolkit.home and 
then add
the gwt-dev dependencies yourself. This causes the plugin to attempt to append
non-existent jars at the beginning of the classpath. But since your classpath 
will
already include the gwt-dev jar and zip (in whatever order you declared in your 
pom),
it all works out dandy.

I'm using 2.0-beta20.

Original comment by kind...@gmail.com on 5 Sep 2008 at 7:29

Attachments:

• issue105-workaround.txt

[GoogleCodeExporter]

Are you guys using GWTx with 1.5?  Seems there is some discussion about that, 
and
whether or not it works:
http://code.google.com/p/google-web-toolkit/issues/detail?id=923. 

I used it the other day, but I just ripped the source out and put it in a local
module just for PropertyChangeSupport (and related).  I did not import the 
actual
GWTx stuff.  

It still might be good to be able to specify the order of the injected gwt-user 
and
gwt-dev jars (and I have a few other clean up tasks related to those so they 
don't
get added multiple times, which could happen currently) - but I don't think 
this is
all that relevant for 1.5 anyway (with GWTx on the fence itself)?  

Original comment by charlie....@gmail.com on 9 Sep 2008 at 12:26

[GoogleCodeExporter]

I am going to look into how Maven 2.0.9 does it, keeping the order the same as 
in the
POM even when transitive, and accommodate that.  That should allow order 
specification.

Original comment by charlie....@gmail.com on 11 Sep 2008 at 11:14

• Changed state: Accepted

[GoogleCodeExporter]

We are working on this now via issue 148.  I would close that as a dupe and 
leave
this, but both of these now have patches (and I think 148 has more up to date 
info).
 I am going to comment on 148 to reference back to this one (valuable info here too),
but close this one to keep things consolidated. 

Original comment by charlie....@gmail.com on 17 Sep 2008 at 3:00

• Changed state: Duplicate