Re: gwt-maven-archetypes multiple project setup

After more development I have another question regarding this multi project set up so that the compiler can detect changes in the source code when running super dev. Everything works correctly if I declare the sibling projects (library-core in this case) as modules in the parent pom of the web app project. However, I think this is not the best practice. For instance, if I had the library deployed and not checked out locally I would want it to resolve the dependency, this would cause an error with the pom trying to find the sibling project. But if I do have the library checked out locally, my goal is to have a set-up where I don't have to declare sibling projects as modules and the incremental compile works when running super dev (changes in any project's java files are detected and a packaging is not required).

While looking for a solution I found the lifeycle mapping here:

https://github.com/tbroyer/gwt-maven-plugin/blob/master/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml

I notice that on the import-sources goal, the action is ignored. If instead runOnIncremental was set to true wouldn't the resolution of artifacts from the local workspace work with incremental compile? Can you help me understand why you set this to ignore and what is the best way to set up the projects so that changes in the library are detected when running super dev even if the module is not declared in the parent pom of the web app?

Hope that all makes sense.

Thanks,

Will

On Friday, July 24, 2015 at 10:42:19 AM UTC-4, Thomas Broyer wrote:

On Friday, July 24, 2015 at 4:13:45 PM UTC+2, William Davis wrote:

I think I figured something out. In the "base" project, in the parent pom, I only defined the three modules in that project like this:

<modules>

    <module>base-client</module>

    <module>base-shared</module>

    <module>base-server</module>

  </modules>

but I changed it to add the client library like this:

<modules>

    <module>base-client</module>

    <module>../library-core/library-core-client</module>

    <module>base-shared</module>

    <module>base-server</module>

  </modules>

and now the incremental compile works when I make changes to the library client.

Is this the correct/best way to do this?

With your initial setup, the library-core-client (and its transitive dependencies) come from your local repository, and you have to "mvn install" the library each time you make a change to it.

With your final setup, it's all one reactor project (you should include the library-core-shared and library-core-server too BTW), so the gwt-maven-plugin will look at the MavenProject from the reactor build to get its sources.

Your initial setup is OK if you intend to release library-core-* separately from the "base" webapp.

Your final setup is OK if you intend to release everything at once. I'd have rather put everything inside one big project with many submodules (organized into subfolders), but in the end it's up to you to decide.

Note that there's a way to get things working with your initial "2 separate projects" approach though: create a POM file somewhere that lists all modules as submodules (note: you can just list the 2 root modules of your 2 projects and thus get the submodules recursively) and from which one you can run the tomcat7:run and gwt:codeserver goals.

This is all "standard Maven", independent of the gwt-maven-plugin (you'd get the same behavior for server-side code with the tomcat-maven-plugin, not seeing changes to your library-core-shared and library-core-server until you "mvn install" them and restart Tomcat).

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.