Bumps jackson.version from 2.10.2 to 2.12.1. Updates jackson-annotations from 2.10.2 to 2.12.1 <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li> </ul> </details> <br />

Updates jackson-databind from 2.10.2 to 2.12.1 <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Sorry to spam this issue (isn't really a separate issue) but in case somebody ran into the same issue:

IntelliJ won't import dependencies if they are using with the gwt-lib type. To fix this, one has to go to FIle -> Settings -> Maven -> Importing and add gwt-lib to the list of automatically imported dependencies.

If we call it a problem then it's still present. I fugured out that the NPE happens i.e. if you mess up the dependencies in your pom.xml with two entries for the same dependency (one with type gwt-lib and the second without any classifier). The plugin version I used for that is 1.0.0, GWT version 2.9.0, maven 3.6.3.

...just wanted to give my two cents here if someone comes by with the same problem.

I haven't tried this, but I wonder:

Is the Maven goal for DevMode working with GWT 2.9.0 , or is it suffering from the known GWT 2.9.x build classpath symptoms as the ones mentioned under (https://github.com/gwtproject/gwt/issues/9720) and the referenced issues

Thanks for confirming.

I was referring to "Super DevMode" not standard "DevMode", which I am using via "Google Plugin for Eclipse" but I have to agree that even though "codeserver" is not as simple it at least bypasses the Jetty runtime classpath issues.

Don't use DevMode except for static files in standalone / client-only apps, it's as simple as that: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html

But to answer your question, given that this plugin only runs GWT in forked JVMs, without any modification or even classpath/classloader tricks, then yes it suffers from the same limitations. The advice above applies to GWT generally, whether run through this plugin or anything else (Ant, Gradle, your IDE, etc.)

I haven't tried this, but I wonder:

Is the Maven goal for DevMode working with GWT 2.9.0 , or is it suffering from the known GWT 2.9.x build classpath symptoms as the ones mentioned under (https://github.com/gwtproject/gwt/issues/9720) and the referenced issues

That should be clearly stated in the documentation ! This is a very common usage.

plugin is 99% IDE-agnostic This confirms my original suspicion that the plugin is not meant to work with "GWT Eclipse Plugin".

I agree, it is a GWT Eclipse Plugin issue.

Thanks for the advice, I will try to make my projects IDE-agnostic.

This is a very good directional shift towards better structured GWT projects.

However, the compatibility with "GWT Eclipse Plugin" seems partially broken.

Projects built with this plugin are still recognized by "GWT Eclipse Plugin" but somehow the WAR source files are not copied to the running area.

Would it be correct to assume that due the change in direction this plugin is not meant to work with "GWT Eclipse Plugin"? If yes, then this will disappoint many supporters of "GWT Eclipse Plugin", myself included.

I am very well aware of the runtime classpath issues caused by strong dependency of "gwt-dev" to hardcoded version of "Jetty" and frankly this will always be a problem, with or without use of "GWT Eclipse Plugin". Yet, I believe "GWT Eclipse Plugin" is still useful.

Regarding your attached project: the project is not a gwt-app, or at least it's "not only" a gwt-app: it includes an src/main/webapp that no plugin is going to use (the maven-war-plugin is not bound to any phase, so its configuration is mostly useless, unless you specifically call its goals from the command line, such as mvn war:war, but then it'll conflict with the gwt:compile and/or gwt:package-app goals.

This probably explains why it doesn't quite "work" in Eclipse either.

What I'm saying is that this plugin is 99% IDE-agnostic: the only exception is this file. On the other hand, the GWT Eclipse Plugin has specific code to handle projects using this plugin.

Also, once you've imported the project into Eclipse, you're not using the Maven plugin anymore; the "Run as..." actions are purely Eclipse things, and I have zero idea what they're doing and how they work.

So this is 100% a GWT Eclipse Plugin issue.

BTW, the GWT Eclipse Plugin is a one-man project that hasn't been maintained for more than 2 years now. If I had one advice, it would be to try to make your projects IDE-agnostic; Gradle makes this easier, but there are ways to do it with Maven too (and this plugin tries to make it easy/easier): https://github.com/tbroyer/gwt-maven-archetypes (you'll notice that the Tomcat Maven Plugin is unmaintained too, so use Jetty, despite the necessary hacks to make it work in a reactor build, or enjoy the Maven limitations and mvn install your modules before you can call a plugin, such as Cargo or whatever you need to run your web server, in a specific submodule)

Well said.

Unfortunately, I cannot ask "GWT Eclipse Plugin" team to investigate an integration problem with a solution from another vendor, I am certain they will send me back to you, or some teams coordination quite difficult to establish will be required.

Equally, I appreciate this is not your area of responsibility either.

I think I will stay with the legacy "GWT Maven plugin" for now, which does work with "GWT Eclipse Plugin".

I'll have a look at your reproducer but this issue should be in the GWT Eclipse Plugin issue tracker, this is where IDE integration is done.

test-GWT.zip Here is a set of Maven projects I prepared which demonstrates the behavior of both Maven GWT plugins. You can import this in Eclipse of recent version (I used 4.14) with "GWT Eclipse Plugin" installed and "Run As / GWT Development mode with Jetty". Notice that the "test.GWT.legacy" project runs as expected but the "test.GWT.tbroyer" project gets recognized by "GWT Eclipse Plugin" but doesn't deliver the required "index.html" file.

This is a very good directional shift towards better structured GWT projects.

However, the compatibility with "GWT Eclipse Plugin" seems partially broken.

Projects built with this plugin are still recognized by "GWT Eclipse Plugin" but somehow the WAR source files are not copied to the running area.

Would it be correct to assume that due the change in direction this plugin is not meant to work with "GWT Eclipse Plugin"? If yes, then this will disappoint many supporters of "GWT Eclipse Plugin", myself included.

I am very well aware of the runtime classpath issues caused by strong dependency of "gwt-dev" to hardcoded version of "Jetty". Yet, I believe "GWT Eclipse Plugin" is still useful.