On Thursday, March 16, 2017 at 5:10:24 PM UTC+1, Magnus wrote: > > Hello, > > I am evaluating the interplay of maven and eclipse with two simple > projects: > > - a simple GWT application based on the one created with webAppCreator > - a simple library containing both, pure java code and GWT code > > During my evauation, I have seen several problems like this: > > After making changes to the app or the library, which is used by the app, > what should be done to get everything up to date? > > - cd lib; mvn clean compile package install > or a subset of these? > > the 'install' phase comes after 'package', which comes after 'compile', so "mvn clean install" is equivalent. See https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> > - cd app; mvn clean compile package gwt:devmode > or a subset of these? > > Same as above, 'compile' is redundant with 'package' (and 'gwt:devmode', see https://tbroyer.github.io/gwt-maven-plugin/devmode-mojo.html; gwt:devmode invokes 'process-classes', which comes after 'compile') 'package' should only be needed once (after a 'clean') and could be speed up by skipping the GWT compilation (when you want to overwrite the output with SDM's stub *.nocache.js anyway) with -Dgwt.compiler.skip. "mvn gwt:devmode" should be enough most of the time, and from time to time "mvn clean package -Dgwt.compiler.skip" as an intermediate step. And when you need to deploy a "production ready" artifact, then "mvn verify" (or "mvn package" if you don't have integration tests) and pick the WAR in the target/ folder. But if the lib and app are part of the same "project" (same release cadence, etc.) then you'd better setup a multi-module build; then the "lib" could be resolved from the reactor when building "app" without the need to 'install' it first. Then you should only need to "mvn gwt:devmode" (devmode being configured in the root POM, not the GWT app; see my archetypes for examples of that) for the whole project (from time to time, "mvn clean package -Dgwt.compiler.skip"). > And in eclipse: > > - lib project: refresh and/or Maven -> Update Project ... and/or GWT > -> compile? > > Refresh might be necessary if you changed files on disk outside Eclipse, but otherwise shouldn't be needed. AFAIK, Maven → Update Project… is only necessary when making changes to the POM. Libraries are by definition not GWT apps, so no GWT → compile here. > - app project: refresh and/or Maven -> Update Project ... and/or GWT > -> compile? > > Same as above. Wrt GWT → compile, it depends what you want to achieve. > Relating to the two projects in eclipse: > > - should the library project be defined as a "required project" on the > build path of the app project? > > > - should the jar file produced by the library project be added to the > build path of the app project? > > In essence: Should you "repeat" those dependencies in eclipse, allthough > they are already defined in the pom.xml files? > No; M2Eclipse should take care of that for you (and could possibly resolve the "lib" Maven dependency from the Eclipse workspace, as if you had a reactor build) Basically, when using "smart" build tools like Maven or Gradle (and by that I mostly mean that the project configuration in the IDE –mostly build path– can be automatically inferred from the build "script"), your IDE becomes hardly more than a "smart text editor", providing syntax highlighting, completion, refactoring, etc. With good plugins in the IDE (and I believe the GWT Eclipse Plugin is one of them), you can then also run things from the IDE without worrying about whether they're correctly configured, because the configuration comes from the project model (POM in the case of Maven). If you don't "trust" your IDE, then you can delegate to the build tool instead (that's what I do; not that I do not "trust" my IDE, but why worry about whether your IDE configuration will work if you know the command line works? I know Brandon put a lot of effort on launching things within Eclipse, with possibly a better developer experience with auto-deploy on file change or things like that that you don't necessarily have with the command line tools; so "pick your poison") For me, it's still unclear, how the development process looks like, > especially when you have a separate library project. > It depends if the library really is "separate" (i.e. *released* separately) or not. Things are much easier with multi-module, reactor build. And you can actually use a reactor build to "bring together" separate projects. So, actually, the problem is that there are many ways to work, some of them depend on project constraints, so it's hard to give generic advice. -- 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+unsubscr...@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.
