Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Migrate to the new generation gwt-maven-plugin

See original GitHub issue

CQ:

https://dev.eclipse.org/ipzilla/show_bug.cgi?id=14390

Related to Che 6 branch only. Should also fix #2595

The goal of this task is migrate from the legacy org.codehaus.mojo:gwt-maven-plugin (aka Mojo’s) to the new one - net.ltgt.gwt.maven:gwt-maven-plugin.

Cons of the legacy plugin:

since 7 Apr 2017 Mojo’s maven plugin has been considered as a legacy;
designed a long time ago when most of the GWT projects contained client, server and shared code within the same maven module. So the old plugin promotes hacking to make it work. E.g. it’s really hard to configure launching Super DevMode from the command line regardless of the used IDE;
Mojo’s plugin is tightly linked to a specific version of GWT.

Some of the advantages of the new plugin:

the new plugin is considered as the new generation GWT maven plugin and it’s strongly encouraged to use it instead of the legacy one;
designed from the beginning with multi-module projects in mind and follows best practices;
independent of the GWT version (should work with GWT version provided by the gwt-dev dependency).

Opportunities Che will get with the new plugin:

better UX for plugins’ developers:
- flexible options for generating GWT-module descriptors (.gwt.xml):
  - it may be generated automatically if you follow the provided layout
  - it may be generated from a template
  - <inherits> may be generated from the project’s dependencies
proceeding from the previous points we don’t need to use our GwtXmlGenerator with exec-maven-plugin execution;
correct work with multi-module projects, e.g., Super DevMode.

To migrate to the new plugin we need:

use gwt-lib lifecycle/packaging for all artifacts with client code;
use gwt-app lifecycle/packaging for assembly-ide-war;
slightly adapt projects structure according to the layout provided by the new gwt-maven-plugin;
avoid using GwtXmlGenerator;
get rid of Mojo’s gwt-maven-plugin.

Issue Analytics

State:
Created 6 years ago
Reactions:10
Comments:6 (6 by maintainers)

Top GitHub Comments

1reaction

azatsarynnyycommented, Oct 20, 2017

Short status update. The new gwt-maven-plugin is already in use for compiling IDE in Che 6 (see https://github.com/eclipse/che/pull/6822). So now we do not depend on the legacy gwt-maven-plugin. Currently, I’m finalizing Che’s maven modules adaptation for gwt-lib/gwt-app lifecycle.

0reactions

azatsarynnyycommented, Oct 31, 2017

Has been done in https://github.com/eclipse/che/pull/7084

Top Results From Across the Web

MIgrating from legacy gwt maven plugin to new generation ...

I'm looking to see if we can migrate from the current legacy (mojo) GWT Maven plugin to the new generation (ltgt) Maven plugin....

Migrating from Mojos Maven Plugin for GWT

The module is managed in src/main/module.gwt.xml by default. When migrating your project, you have to either move your module file to src/main/ ...

gwtproject/gwt - Gitter

I am using the app engine maven plugin. new generation gwt-maven-plugin ... will get inspired and will migrate to the new generation gwt-maven-plugin...

Support next generation gwt-maven-plugin directory structure

You can just open the IntelliJ settings and add gwt-lib to the maven > importing > dependency types .

Mojo's Maven Plugin for GWT - general questions

The Google Plugin for Eclipse automatically handles launching DevMode with a simple right click on your module gwt.xml file "run as > web...