[GWT] Multi Module Hot Code Development (Development Mode)

[Andrew Hughes]

Like most projects, our GWT client is getting pretty big and it would sensible to break it up into several maven modules.

For example:

+parent

  +server (jar)

  +shared (jar, with source attached)

  +client-a (jar, with client-c.gwt.xml)

  +client-b (jar, with client-c.gwt.xml)

  +client-c (jar, with client-c.gwt.xml)

  +client (war, with client.gwt.xml)

If I run "gwt:run" (to launch the gwt development mode) from the "client" module I won't see any hot code changes from modules client a,b and c (will I???). It won't get the new code until I close the dev console, run mvn install and re-run "gwt:run". Please tell me that I am completely wrong and this is not the case. Dividing up our gwt client into modules seems good in theory, but I don't want to it to be detrimental to the development mode.

Cheers :)

--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.
To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

[Andrew Hughes]

Ooops, there is a few copy paste typo's in the module-X.gwt.xml naming below... please forgive me and ignore the inappropriately named .gwt.xml files :)

[Jesse Farinacci]

Hi Andrew,

On Fri, May 21, 2010 at 2:23 AM, Andrew Hughes <ahhu...@gmail.com> wrote:
> Like most projects, our GWT client is getting pretty big and it would
> sensible to break it up into several maven modules.

The problem you describe has some pretty bad solutions. Some of them
are discussed on the plugin page itself[1]. I find that, in practice,
I rarely want hot code replace from another module. I'm usually just
ensuring that all the small GWT modules are playing nicely together..
if you find that you're frequently updating multiple GWT module
sources simultaneously, then I would question why you've split them up
to begin with -- that, or, perhaps you should consider doing more work
on the individual modules before you try to integrate.

-Jesse

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


--
There are 10 types of people in this world, those
that can read binary and those that can not.

[Andrew Hughes]

Hi Jesse,

They are very good points (all of which have crossed my mind). I think I might be asking to bend too many rules here :)

My main motivation was to seperate them is to prevent circular dependencies/references that break our MVP architecture (standard SoC). These rules are what's important and it won't matter if they are being worked on simultaneously (hot deployed) or not. Sure, "waterfall" like dependencies/deploy's are nice in theory - but in reality they are transient and the only thing that is likely to change is the time I waste restarting the dev mode and running install (probably with -Dmaven.test.skip=true to save time as well).

I could make more of an effort to have (child) modules with <packaging>jar</packaging> but run them as if they were a war with gwt:run. This has worked ok for hot deploying at each "level", but does have overheads.

Thanks heaps for the reply :)

[Ladislav Gazo]

You are absolutely right, dev mode will not detect your JAR changes of
dependent modules but... if you are developing a solution and using
Maven + GWT-maven plugin + Eclipse + Eclipse GWT plugin you can
achieve the effect of propagating changes in one of the dependent
modules to the overall running application in dev mode. Dev mode is
able to detect changes in source codes and compiled classes and by
binding dependent modules on source level it allows you to run & debug
the application without the need to reinstall them to maven
repository.
You can check the neccessary steps here http://gwt.sk/2009/09/22/1253633489945.html
but in general by running maven install, eclipse:eclipse, gwt:eclipse
goals and import the launcher you get what you need (hopefully I
understand your concerns clearly :)

> For more options, visit this group athttp://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?h....

[nicolas de loof]

Could you contribute this interesting doc to the plugin ?

2010/5/21 Ladislav Gazo <ladisl...@gmail.com>

[Ladislav Gazo]

I don't recall it exactly but think I sent it long time ago,
nevertheless I can create version suitable for your wiki.

On 21. Máj, 19:16 h., nicolas de loof <nicolas.del...@gmail.com>
wrote:

> Could you contribute this interesting doc to the plugin ?
>

> 2010/5/21 Ladislav Gazo <ladislav.g...@gmail.com>

> > codehaus-mojo-gwt-maven-...@googlegroups.com<codehaus-mojo-gwt-maven-plugin-users%2Bunsu...@googlegroups.com>
> > .

> > > For more options, visit this group athttp://
> > groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?h....
>

> > --
> > You received this message because you are subscribed to the Google Groups
> > "Codehaus Mojo gwt-maven-plugin Users" group.
> > To post to this group, send email to
> > codehaus-mojo-gwt-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > codehaus-mojo-gwt-maven-...@googlegroups.com<codehaus-mojo-gwt-maven-plugin-users%2Bunsu...@googlegroups.com>
> > .

[Ladislav Gazo]

ok, I have it prepared, I was not able neither to commit it (don't
have rights) nor generate HTML. I issued mvn site in maven 2.0.10 and
2.1.0 but none of them passed through. How should I send it? Should I
create JIRA issue with ZIP?

On 21. Máj, 19:16 h., nicolas de loof <nicolas.del...@gmail.com>
wrote:

> Could you contribute this interesting doc to the plugin ?
>

> 2010/5/21 Ladislav Gazo <ladislav.g...@gmail.com>

> > codehaus-mojo-gwt-maven-...@googlegroups.com<codehaus-mojo-gwt-maven-plugin-users%2Bunsu...@googlegroups.com>

> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?h....
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Codehaus Mojo gwt-maven-plugin Users" group.
> > To post to this group, send email to
> > codehaus-mojo-gwt-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > codehaus-mojo-gwt-maven-...@googlegroups.com<codehaus-mojo-gwt-maven-plugin-users%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?h....
>
> --
> You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.
> To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
> To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?h....

[Andrew Hughes]

Howdy,

Thanks very much for this solution. There are some considerations with this and perhaps I am wrong. If so, please correct me :)

The solution appears to detach all upstream (gwt module) maven dependencies with the "disable workspace resolution" option...

Q: am I wrong about this?

The solution then effectively "substitutes" the missing maven dependency by adding the source directory of the upstream dependency to the Eclipse project (i.e. ../other-module/src/main/java).

Q: would this drop all dependencies including the server side dependencies (jars, even the gwt ones?). If so then it's definately problematic, time consuming, and probably non-portable (without some kinda maven depedenency:copy goal manually invoked first).

If I'm right (thats a big IF) I'd like to consider another possibility...

It's possible that the downstream maven module contain a specific profile say "gwt-hotdependencies". The profile could switch the selected (gwt client module) dependencies off so that you are not running against the jar's. Instead, just like your example you could append another module(s) source directory (../other-module/src/main/java) to the Maven project using the buildhelper plugin (see http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html). What's good about this is that you still have your server side dependencies loaded by maven, it's portable and it's going to work in every ide.

Anyway, I'm trying my best here - sorry if I am totally wrong, this problem is really plaguing us.

CHEERS :D

--AH

For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

[Andrew Hughes]

I had a chat to the m2eclipse guys, I'm out of my depth here but I think this is on the right track (for eclipse hot deploy anyway).

There's an m2e-extra's feature called "Project configurators for commonly used maven plugins (temporary)" available on m2e-extras update site. Then you can use a  custom lifecycle mapping with <configurator id="org.maven.ide.eclipse.buildhelper.buildhelperConfigurator"/>

Apparently this will do exactly what we need -- add additional sources defined by add-source and add-test-source mojos to .classpath file

This is also relevant https://docs.sonatype.org/pages/viewpage.action?pageId=2949459

Night guys, I've run out of energy feel free to comment on this :)