On Saturday, February 23, 2019 at 12:55:17 PM UTC+1, Ralph Roland wrote:
Given your description, you could create fewer Maven modules (I'm not saying you should do it, but you could)
-- I'm considering migrating an existing application from being built with Ant, to being built with Maven.I've been doing a lot of reading and experimenting with the net.ltgt.gwt.maven gwt-maven-plugin but can't seem to wrap my head around the specifics of moving our existing application to the multi-(maven)module model recommended for this plugin.This application is really two apps in one (each with a separate EntryPoint) plus a third 'common' gwt-module plus supporting common java classes, etc. Both App-A and App-B GWT modules "inherit" the Common GWT module. Finally a separate control servlet acts the front-end and returns HTML invoking the correct GWT javascript (App-A or App-B) based on the requested URL.Our current project structure is:Projectsrccomfooapp_aclient<client-side (GWT related) classes>AppAEntryPoint.javaserver<server-side classes>shared<classes shared by client and server packages>App_A.gwt.xmlapp_bclient<client-side (GWT related) classes>AppBEntryPoint.javaserver<server-side classes>shared<classes shared by client and server packages>App_B.gwt.xmlcommonclient<client-side (GWT related) classes>server<server-side classes>shared<classes shared by client and server packages>Common.gwt.xml (no <entry-point> defined)warWEB_INFlib<dependent jars>My best guess right now for migrating the structure would be to break this into 3 separate projects (App-A, App-B and Common) each with 3 maven modules (App-A-client, App-A-Server, App-A-shared, App-B-client, etc...) But this seems a bit extreme in that we would end up with 12 distinct Eclipse projects, with code 'spread' across 9 of those. I feel like if App-A and App-B didn't have their own EntryPoints that I could easily transform this to fit the multi-module archetype structure, but the multiple EntryPoints keeps tripping me up.Is there something obvious (or not) that I'm missing that would allow our app to 'live' in the (relatively simple) archetyped structure?
* shared, with common.shared, app_a.shared and app_b.shared
* common-client, as a gwt-lib, with common.client, and depending on shared and shared-sources
* app_a, as a gwt-app, with a dependency on common-client and shared (and shared-sources), though that one is also brought transitively through common-client
* app_b, as a gwt-app, with a dependency on common-client and shared (same as app_a)
* server, as a war, with common.server, app_a.server and app_b.server, and a dependency on shared.
Note that you could technically also use a single Maven module mixing client and server code, but this means your server-side dependencies are in your client code classpath (compile and "runtime"), and your client-side dependencies are in your server compile classpath (not runtime if you correctly exclude them from your WAR). If that's how you manage your classpaths with Ant, then it could provide an easier migration path to Maven; see https://github.com/gwtproject/gwt/blob/2.8.2/user/src/com/google/gwt/user/tools/templates/maven/pom.xmlsrc for an example setup (this is the template used by GWT's WebAppCreator)
BTW - my main reason for wanting to move to a maven-based build is to manage the dependent jars in the web-inf/lib directory.
If that's your main driver and you're otherwise OK with Ant, then maybe have a look at Ivy.
You received this message because you are subscribed to the Google Groups "GWT Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment