[ANN] net.ltgt.gwt.maven:gwt-maven-plugin:1.0-alpha-1 released

[Thomas Broyer]

Hi everyone,

Last night (UTC+1), I released 1.0-alpha-1 of my net.ltgt.gwt.maven:gwt-maven-plugin.

Preliminary documentation is available at https://github.com/tbroyer/gwt-maven-plugin

Note that this is an early alpha:
 • As an experiment, the GWT compiler runs inline rather than in a forked process (which also means it only uses threads for now and won't fork worker processes); forking will likely become an option behind a flag (similar to the maven-compiler-plugin).
 • There's no way to launch the DevMode or SuperDevMode. I want something that works in multi-module builds, contrary to the org.codehaus.mojo:gwt-maven-plugin.

Unless someone opposes to it, this plugin will likely become com.google.gwt.maven:gwt-maven-plugin in the near future (with the stated goal of replacing the Codehaus Mojo plugin in the long run).

Note: this forum is about GWT proper, so please keep feedback on this specific thread, the G+ announcement (see link below), the other announcements in the GWT and gwt-maven-plugin forums, or possibly on Twitter (@tbroyer).

“Illustrated announcement” at: https://plus.google.com/113945685385052458154/posts/RDrK7ukVFqJ

[Hilco Wijbenga]

On 25 March 2013 02:22, Thomas Broyer <t.br...@gmail.com> wrote:
> Preliminary documentation is available at
> https://github.com/tbroyer/gwt-maven-plugin

Is it possible to combine multiple "gwt-lib"s into a "gwt-app" without
re-gwt-compiling everything? Because that would be awesome. :-)

> Note that this is an early alpha:

> • There's no way to launch the DevMode or SuperDevMode. I want something
> that works in multi-module builds, contrary to the
> org.codehaus.mojo:gwt-maven-plugin.

What exactly doesn't work when running gwt-maven-plugin in
multi-module builds? We've been doing that for at least a year and I
have never noticed a problem?

[Thomas Broyer]

On Mon, Mar 25, 2013 at 4:46 PM, Hilco Wijbenga
<hilco.w...@gmail.com> wrote:
> On 25 March 2013 02:22, Thomas Broyer <t.br...@gmail.com> wrote:
>> Preliminary documentation is available at
>> https://github.com/tbroyer/gwt-maven-plugin
>
> Is it possible to combine multiple "gwt-lib"s into a "gwt-app" without
> re-gwt-compiling everything? Because that would be awesome. :-)

Incremental compiling is on the roadmap for the GWT Compiler; as far
as the gwt-maven-plugin is concerned, a gwt-lib is just a JAR
(generally with a META-INF/gwt/mainModule file) and a gwt-app is a WAR
(without WEB-INF/, only the output from the GWT Compiler)

>> Note that this is an early alpha:
> > • There's no way to launch the DevMode or SuperDevMode. I want something
>> that works in multi-module builds, contrary to the
>> org.codehaus.mojo:gwt-maven-plugin.
>
> What exactly doesn't work when running gwt-maven-plugin in
> multi-module builds? We've been doing that for at least a year and I
> have never noticed a problem?

It's gwt:run and gwt:run-codeserver only that are a problem with
multi-module builds.
See https://jira.codehaus.org/browse/MGWT-332,
https://github.com/tbroyer/gwt-maven-archetypes/pull/13 and
http://stackoverflow.com/q/10686682/116472 (jetty-maven-plugin has the
same issue, tomcat-maven-plugin works great)


--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Jens]

Would you provide me with some examples about gwt-lib or gwt-app? I do need some tutorials about how to use this new library.

You can look at the integration test examples at https://github.com/tbroyer/gwt-maven-plugin/tree/master/src/it

Most likely gwt-app, gwt-lib and, for a bit more complex scenario, e2e.

-- J. 

[Thomas Broyer]

You can also find real uses of gwt-lib in the wild (so you can omit
the <inherits/> in your gwt-app!):
https://github.com/google/gwtmockito/ and
https://github.com/google/gwteventbinder

[Thomas Broyer]

On Tue, Jun 4, 2013 at 4:31 PM, Lexis Nexis <lexisne...@gmail.com> wrote:
> They are very useful. Thanks.
>
> How do I generate a gwtar file if I use this plugin?

You don't ;-)

AFAICT gwtar files are highly dependent on the version of GWT used to
produce them, so you won't want to create them for a library you
intend for "wide" reuse.

>
> David

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/O8HaPzExxhc/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> google-web-tool...@googlegroups.com.
> To post to this group, send email to google-we...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Lexis Nexis]

I have the following two questions:
1. Can we have more sub source folders under src/main such as src/main/java, src/main/gwt for GWT, src/main/birt,for BIRT, src/main/config for Spring Java configuration.
2. I have a huge project (> 1000 database tables). I like to generate many gwtar files for my internal team in order to reduce gwt compilation time. How do I do it? Should I use CompileModule from prompt? I like to get one script how to generate a gwtar file?

Thanks,

[Thomas Broyer]

On Tuesday, June 4, 2013 8:24:53 PM UTC+2, Lexis Nexis wrote:

I have the following two questions:
1. Can we have more sub source folders under src/main such as src/main/java, src/main/gwt for GWT, src/main/birt,for BIRT, src/main/config for Spring Java configuration.

gwt-lib and gwt-app packagings are for GWT code only (gwt-app will only package the generated JS/HTML); you shouldn't mix client and server code in the same Maven module (you can make a "shared" module, but then I think you shouldn't bundle your gwt.xml, sources and super-sources within that JAR; YMMV). Have a look at the e2e integration test for an example, and see http://blog.ltgt.net/announcing-gwt-maven-archetypes-project/ for the rationale (well, I think I explained it in this blog post).

Otherwise, well, they'll use all source roots and resources so you can have as many as you want (e.g. some plugin that generates Java sources and adds the folder as a source root; or using the build-helper-maven-plugin to add a folder from src/main as a source root; it doesn't matter where the source root comes from).

 

2. I have a huge project (> 1000 database tables). I like to generate many gwtar files for my internal team in order to reduce gwt compilation time. How do I do it? Should I use CompileModule from prompt? I like to get one script how to generate a gwtar file?

I'd call CompileModule using the exec-maven-plugin then. At the process-classes or prepare-package phases, everything (compiled classes and their sources, and resources) should be in the ${project.build.outputDirectory} so you shouldn't have to deal with the classpath and can just use ${project.build.outputDirectory} as the -out folder for CompileModule.

I'm curious now: did you measure the gains? I've been told Google actually doesn't use gwtar for their internal libs and given how their build system works they can't take advantage of the PersistentUnitCache from previous runs; admittedly they have huge build resources but we also know that speed matters for them, so if they could save some time in downstream compilations I'd think they'd use the existing tool (CompileModule) for that?

[Lexis Nexis]

I got the following error Once I run mvn -V gwt:compile for gwteventbinder-master. What am I missing?

----------------------------------------------------
C:\gwt\gwteventbinder-master>c:\apache\maven\3.0.5\bin\mvn -V gwt:compile
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: c:\Apache\maven\3.0.5\bin\..
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_35\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] EventBinder (Parent)
[INFO] EventBinder
[INFO] EventBinder Sample Application
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building EventBinder (Parent) 1.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- gwt-maven-plugin:1.0-alpha-2:compile (default-cli) @ eventbinder-parent ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] EventBinder (Parent) .............................. FAILURE [0.213s]
[INFO] EventBinder ....................................... SKIPPED
[INFO] EventBinder Sample Application .................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.130s
[INFO] Finished at: Wed Jun 05 12:30:33 EDT 2013
[INFO] Final Memory: 8M/151M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.0-alpha-2:compile (default-cli) on project eventbinder-parent: The parameters 'mo
duleName' for goal net.ltgt.gwt.maven:gwt-maven-plugin:1.0-alpha-2:compile are missing or invalid -> [Help 1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------

[Thomas Broyer]

As the error says, gwt:compile needs the module name to be supplied,
and it obviously isn't on "EventBinder (Parent)" which has
packaging=pom.

Why are you calling gwt:compile directly? gwt:compile is bound to the
prepare-package phase of the gwt-app packaging so just use "mvn
package" (or "mvn prepare-package").

[Thomas Broyer]

On Saturday, June 8, 2013 1:22:30 PM UTC+2, Oliver O. wrote:

Thomas, thanks for putting all the effort into this.

Thanks for the feedback!

 

I've experimented a bit with 1.0-alpha-2 on a little project with a structure similar to your guice-rf-activities Maven archetype. What I've observed so far:

• When used with GIN 2.0.0, on compiling ${module}.java, the message "The type passed does not inherit from Ginjector - please check the deferred binding rules." appears for the ${module}Ginjector class, followed by a stack trace.
  

The plugin uses its own class loader while GIN's class loader delegates to the system class loader instead of the class loader used to load GIN itself. This apparently causes the same class to be loaded by different class loaders, undermining class identity.

 

If the gwt-maven-plugin alpha is used with a GIN version where the fix for GIN issue 186 has been applied, it works as expected. Unfortunately, this fix is not available in GIN's svn repository yet.

I've opened https://github.com/tbroyer/gwt-maven-plugin/issues/5 to add an option to fork a process.

• On the first run of mvn package after mvn clean, this message appears, followed by a stack trace: [INFO] Unable to create new cache log file .../${module}/${module}-client/target/${module}-client-1.0-SNAPSHOT/../gwt-unitCache/gwt-unitCache-0000013F1E883EF9.

Yes, I think the problem is that ${module}-client-1.0-SNAPSHOT does not exist (yet) so ${module}-client-1.0-SNAPSHOT/../gwt-unitCache fails (strangely, mkdirs() works, but it doesn't directly passed the absolute path down to a native method, it first canonicalizes it)

I think this is a JVM bug, but it could be worked around in GWT (have PersistentUnitCache call getCanonicalFile())

• Successive invocations of mvn package on unchanged sources always compile the GWT module.

This is strange because I have an integration test about this.

Could you please file a bug with a reduced repro case or some more information?

 

The third point is what currently precludes further use of the alpha-2 version. In addition, I still need to figure out how to configure a draft compile for just one user agent. In the guice-rf-activities archetype there was a separate gwt.xml module file for that. Now it seems that module file names are somewhat hard coded into the plugin. However this one is not that important as one might introduce a code generation step for the module file.

Feel free to file an issue. Not sure how to deal with it yet. (should the src/main/module.gwt.xml path be configurable? should things be configurable in the pom.xml?)

 

I've also read your well written analysis in the blog post In quest of the ultimate build tool, so I'm curious how this might work out. For now, I would appreciate if Maven could be tamed to nicely support multi-module GWT builds and the new plugin looks promising to me.

That's the goal of that plugin. The CodeHaus plugin looks more like a hack than a full-thought-out solution.