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 "com.google.gwt.http.client.Request" 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"
--
Olivier Lamy on behalf of the The Maven Team
PS : pushing open source release is fun The famous song :-)
3 comments:
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,
-fotos
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.
-Olivier
Hey,
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/CrossSiteIframeLoadingStrategy.java'
00:00:23.969 [ERROR] Line 21: The import com.google.gwt.core.client.impl.AsyncFragmentLoader.LoadTerminatedHandler 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
0.0.0.0
I tested this in both versions of the plugin 2.1.0 and 1.3-SNAPSHOT, but still it will bind to 127.0.0.1.
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 ${project.build.outputdirectory} 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,
-Yannis
Post a Comment