gwt-dev not in resolved dependecies

[Arthur Kalmenson]

Hello everyone,

I'm using the latest snapshot and have included both gwt-servlet and
gwt-user in my POM. As stated here:
http://mojo.codehaus.org/gwt-maven-plugin/1.1-SNAPSHOT/setup.html
gwt-dev will be automagically resolved. However, that doesn't seem to
be the case because I don't see it as a Maven dependency under Eclipse
and my test cases are failing since they can't find GWTBridge which is
used by the GWTMockUtilities class. Here's the error I get:

java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge
at com.sinai.upma.baseui.client.SomethingTest.beforeMethod(SomethingTest.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:398)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:145)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:427)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:617)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:885)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110)
at org.testng.TestRunner.runWorkers(TestRunner.java:712)
at org.testng.TestRunner.privateRun(TestRunner.java:582)
at org.testng.TestRunner.run(TestRunner.java:477)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:324)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:319)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292)
at org.testng.SuiteRunner.run(SuiteRunner.java:198)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:823)
at org.testng.TestNG.runSuitesLocally(TestNG.java:790)
at org.testng.TestNG.run(TestNG.java:708)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)

If gwt-dev was included, the class would be found. Is there a way to
force gwt-dev to be included in the classpath during the test phase?
Thank you in advance.

Best regards,
--
Arthur Kalmenson

[Arthur Kalmenson]

I've fixed this by include a dependency for gwt-dev and doing the same
profile platform settings as the Google Code plugin:

<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<classifier>${platform}</classifier>
<scope>provided</scope>
</dependency>

....

<profiles>
<profile>
<id>gwt-dev-windows</id>
<properties>
<platform>windows</platform>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
<os>
<family>Windows</family>
</os>
</activation>
</profile>
<profile>
<id>gwt-dev-mac</id>
<properties>
<platform>mac</platform>
</properties>
<activation>
<os>
<family>mac</family>
</os>
</activation>
</profile>
<profile>
<id>gwt-dev-linux</id>
<properties>
<platform>linux</platform>
</properties>
<activation>
<os>
<name>Linux</name>
</os>
</activation>
</profile>
</profiles>

This solved the problem by including gwt-dev as an explicit dependency.

Best regards,
--
Arthur Kalmenson

[Agustín Gañán]

Hi Arthur,

I think it's not a good practice to include this dependency.
Read the "Automatic Mode Setup" section in the setup docs[1]:

"Note : Don't define gwt-dev as project dependency : this JAR has many
common libraries packaged that may conflict with the ones defined for
your project, resulting in uncomprehensible NoSuchMethodErrors. The
gwt-maven-plugin will automagically resolve the required dependency
based on your declared gwt-user dependency."

Regards,

Agus

[1] http://mojo.codehaus.org/gwt-maven-plugin/1.1-SNAPSHOT/user-guide/setup.html


2009/6/2 Arthur Kalmenson <arthu...@gmail.com>:

[Agustín Gañán]

Sorry Arthur, I've just read your first post!!
:$

[Arthur Kalmenson]

It's alright Agustin, no problem :)

--
Arthur Kalmenson



2009/6/2 Agustín Gañán <agu...@gmail.com>:

[nicolas de loof]

For your info the maven plugin has a test goal to support GWT testing that will "automatically resolve gwt-dev"

Cheers,

Nicolas 

2009/5/29 Arthur Kalmenson <arthu...@gmail.com>

[BR]

Hi All,

This is an interesting discussion, and I have an issue.

The module will indeed warn you when you include "dev" in the path -
but what about if you have a code generator (subclass import
com.google.gwt.core.ext.Generator) in your project? Then you DO need
gwt-dev in the classpath to just compile this stuff.

While I am at it, what is the difference between 'gen' and
'generateDirectory' really?

Thanks!
BR

On Jun 2, 11:57 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
> For your info the maven plugin has a test goal to support GWT testing that
> will "automatically resolve gwt-dev"
> Cheers,
> Nicolas
>

> 2009/5/29 Arthur Kalmenson <arthur.k...@gmail.com>

>
>
>
>
>
> > Hello everyone,
>
> > I'm using the latest snapshot and have included both gwt-servlet and
> > gwt-user in my POM. As stated here:
> >http://mojo.codehaus.org/gwt-maven-plugin/1.1-SNAPSHOT/setup.html
> > gwt-dev will be automagically resolved. However, that doesn't seem to
> > be the case because I don't see it as a Maven dependency under Eclipse
> > and my test cases are failing since they can't find GWTBridge which is
> > used by the GWTMockUtilities class. Here's the error I get:
>
> > java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge
> >        at
> > com.sinai.upma.baseui.client.SomethingTest.beforeMethod(SomethingTest.java: 35)
> >        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >        at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9)
> >        at

> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25)

> >        at java.lang.reflect.Method.invoke(Method.java:585)
> >        at
> > org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> >        at
> > org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:398)
> >        at
> > org.testng.internal.Invoker.invokeConfigurations(Invoker.java:145)
> >        at org.testng.internal.Invoker.invokeMethod(Invoker.java:427)
> >        at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:617)
> >        at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:885)
> >        at

> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.jav a:126)

[nicolas de loof]

There is few gwt library that use generators and in such case we can expect developpers to know what they are doing (maybe a parameter could disable this warning). Also notice a library does not need to get compiled by gwt:compile but only to get packaged as a jar (maybe with gwt:resources help)

Anyway, having gwt-dev in the classpath can have serious side-effects as the warning suggest in a webapplication where the server-side code uses some apache commons-* libs that come in gwt-dev. The classpath ordering is then unpredictable (in fact it is, but this would make the build really unsecure)

With those two facts, I'd suggest to package your generator as a separate module (both in maven and gwt sense) and build it separately as a jar with gwt-dev dependency set to provided.

generateDirectory is the standard path for code generators in Maven, to produce additionnal source files (i18n, service Async ...). The gen directory is a gwt compiler hook that can be used to watch what code has been generated by generators, it is not expected to be visible from maven build.

Thansk for your feedback

Best regards, 

Nicolas

2009/6/3 BR <benjami...@gmail.com>

[BR]

Thanks Nicolas. This is helpful.

On Jun 3, 12:31 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
> There is few gwt library that use generators and in such case we can expect
> developpers to know what they are doing (maybe a parameter could disable
> this warning). Also notice a library does not need to get compiled by
> gwt:compile but only to get packaged as a jar (maybe with gwt:resources
> help)
> Anyway, having gwt-dev in the classpath can have serious side-effects as the
> warning suggest in a webapplication where the server-side code uses some
> apache commons-* libs that come in gwt-dev. The classpath ordering is then
> unpredictable (in fact it is, but this would make the build really unsecure)
>
> With those two facts, I'd suggest to package your generator as a separate
> module (both in maven and gwt sense) and build it separately as a jar with
> gwt-dev dependency set to provided.
>
> generateDirectory is the standard path for code generators in Maven, to
> produce additionnal source files (i18n, service Async ...). The gen
> directory is a gwt compiler hook that can be used to watch what code has
> been generated by generators, it is not expected to be visible from maven
> build.
>
> Thansk for your feedback
>
> Best regards,
> Nicolas
>

> 2009/6/3 BR <benjamin.ren...@gmail.com>

[Arthur Kalmenson]

Hi Nicolas,

The original issue was that gwt-dev was not being added during the
test phase and the tests were failing because GWTBridge could not be
found. Is there a way to resolve this and still have it auto add
gwt-dev?

Regards,
--
Arthur Kalmenson

[nicolas de loof]

can you please submit an issue in Jira with a sample project ?

2009/6/24 Arthur Kalmenson <arthu...@gmail.com>