Friday, 5 November 2010

Release Maven Gwt Plugin 2.1.0 (gwt 2.1.0 compatible)

Hi Folks,
The gwt maven plugin version 2.1.0 has been released.
The major change is to be gwt 2.1.0 compatible.

Release Notes - Maven 2.x GWT Plugin - Version 2.1.0

New Feature
  • [MGWT-181] -Add support for GWT compilers -workDir option
  • [MGWT-190] - support GWT 2.1
  • [MGWT-218] - Support for setting the -runStyle parameter for gwt:test
  • [MGWT-191] - gwt:run runs Hosted Mode instead of Dev Mode for GWT 2.1.0.M1

  • [MGWT-110] - Generated interface not identical to interface generated by GWT tooling
  • [MGWT-111] - gwt:run - Multi-module projects with custom start page not well supported
  • [MGWT-118] - GWT Compile fails with IBM JDK
  • [MGWT-129] - Multi module projects doesn't work properly in HostedMode.
  • [MGWT-142] - java.lang.NoClassDefFoundError: com/google/gwt/dev/Compiler when running plugin on Mac
  • [MGWT-147] - GWT modules with inherited entry point are never compiled
  • [MGWT-149] - generateAsync fails with ParseException (ignoring servicePattern?)
  • [MGWT-151] - skip compile when model file not contain entry point.
  • [MGWT-152] - Incorrect documenation on the Maven site
  • [MGWT-155] - Documentation on GWTTesting is incorrect/Broken link
  • [MGWT-161] - gwt-maven-plugin does not work with spaces in project location on Linux
  • [MGWT-164] - Inheriting module does not inherit its <entry-point> or <servlet> definitions
  • [MGWT-165] - scanning for .gwt.xml files doesn't take into account all source roots
  • [MGWT-171] - ServicePattern is ignored
  • [MGWT-183] - Cannot compile a module that inherits a module with entry points
  • [MGWT-186] - Generic Interface is not generated correctly
  • [MGWT-187] - "utility module" detection is incorrect
  • [MGWT-189] - .class files get copied into WEB-INF/classes without package structure
  • [MGWT-198] - AbstractGwtShellMojo hides failure information when executing the compiler process
  • [MGWT-201] - Sources directories in inherited modules are ignored
  • [MGWT-223] - i18n fails under Eclipse with m2eclipse
  • [MGWT-228] - When running with GWT 2.1.0 the plugin require gwt-dev-<platform> jars

  • [MGWT-62] - Possibly bind gwt:compile to the 'prepare-package' phase by default in 'war' projects (maven 2.1)
  • [MGWT-76] - Solution for multi module builds and hosted mode
  • [MGWT-88] - Add mergedWebXml parameter to MergeWebXmlMojo
  • [MGWT-128] - Allow specifying custom environment variables for run/debug goals
  • [MGWT-146] - Explicit setup mode setting
  • [MGWT-148] - Compile also when GWT module file has changed
  • [MGWT-154] - GenerateAsync generate files with unused imports
  • [MGWT-162] - Support for server=n
  • [MGWT-169] - support devmode for multiple modules
  • [MGWT-170] - Find source jars and add them to the classpath when executing the GWT compiler
  • [MGWT-172] - generateAsync suporting "" return objects
  • [MGWT-178] - No messages if a module doesn't contain entry points
  • [MGWT-180] - Add Option for bindAddress
  • [MGWT-194] - Update documentation for /war in GWT 2.0.x
  • [MGWT-195] - create documentation for 'comfortable GWT debugging'
  • [MGWT-225] - Update BCEL dependency to fix the broken pom.
  • [MGWT-188] - Update FAQ re: "NoSuchMethodError"
Have Fun !
Olivier Lamy on behalf of the The Maven Team

PS : pushing open source release is fun The famous song :-)


fotos said...

Monsieur Olivier,

while we do applaud the release of gwt-maven-plugin 2.1, and understand the benefits of being tied to a specific release, we feel you left us behind!

A lot of the bugfixes done in 1.3-snapshot were (and still are) relevant for GWT 2.0.x as well. We even contributed a patch (issue 180) and we 've been patiently waiting for a stable 1.3 release, suitable for use with GWT 2.0.x.

Do you have any plans to release gwt-maven 1.3 with (backported) fixes for GWT 2.0? It would be a great disappointment if you guys didn't, since (big) projects can't upgrade easily but would really benefit from these fixes.

Vous remerciant par avance,

olamy said...

So the mojo gwt 2.1.0 should work with previous gwt version.
So as GWT-180 is closed, you must not have any issue using the last mojo version, if not yes it's an issue.


Giannis said...


I tested the 2.1 plugin with GWT 2.0.4 and even tho it seems to work, it gives the following warnings:
[WARNING] You're project declares dependency on gwt-user 2.0.4. This plugin is designed for version 2.1.0
Shouldn't this be documented somehow?
In the FAQ page of the plugin It says:
"gwt-maven-plugin is tied to a version of GWT SDK. gwt-maven-plugin must match the GWT DSK version. To use Maven with GWT release prior to GWT 2.1, use gwt-maven-plugin 1.2 and read the documentation."
which can be very misleading. As per you comment above, does it work with earlier versions of GWT SDK or not?

Also I see the following errors in the hosted mode:
00:00:23.969 [DEBUG] Validating newly compiled units
00:00:23.969 [ERROR] Errors in 'jar:file:/Users/xxx/.m2/repository/com/google/gwt/gwt-user/2.1.0/gwt-user-2.1.0.jar!/com/google/gwt/core/client/impl/'
00:00:23.969 [ERROR] Line 21: The import cannot be resolved
00:00:23.969 [ERROR] Line 36: The type CrossSiteIframeLoadingStrategy must implement the inherited abstract method AsyncFragmentLoader.LoadingStrategy.startLoadingFragment(int, AsyncFragmentLoader.LoadErrorHandler)
00:00:23.969 [ERROR] Line 99: LoadTerminatedHandler cannot be resolved to a type
etc. I don't know why gwt-user 2.1.0 was loaded in the classpath.

Regarding GWT-180 I added the following lines in my configuration

I tested this in both versions of the plugin 2.1.0 and 1.3-SNAPSHOT, but still it will bind to
I did a little search and found that bindAddress is only related to the gwt:eclipse mojo. What about those that do not use eclipse (like myself)? Should the GWT-180 be reopened again?

One last thing is the following warning:
[WARNING] Your POM does not match your hosted webapp WEB-INF/classes folder for GWT Hosted browser to see your classes.
I don't declare any , it gives me the warning but mvn gwt:run works as expected (since as it says here it respects the ${} as the output directory i.e. target/classes). Is this a "false alarm", since reloading catches up with any source code changes?

Thanks for the 2.1 version of the plugin and your efforts,