GWT version: 2.12 and below
Browser (with version): any
Operating System: any

Description

GWT's TreeLogger class is used in the compiler, and in Generators and Linkers, allowing library/framework code to also meaningfully contribute to log output. Usually, calls to the logger only use the log(Type, String) overload, but technically other overloads exist, including one that can provide an isntance of com.google.gwt.core.ext.TreeLogger.HelpInfo. This class is effectively just a wrapper around a URL.

There aren't many usages of this either, and most are out of date - in fact I didn't even remember that this feature existed until I was trying to clean up other usages of com.google.gwt.util.tools.Utility (which by its package should mostly be used in other cli tools? but instead is used in linkers, HelpInfo, and other assorted places).

Existing usages:

• Concrete subclass com.google.gwt.dev.util.InstalledHelpInfo, takes a file name assumed to be in the GWT SDK zip. When the log message is written, verifies that the gwt-dev.jar came from such a zip, and finds the appropriate file, or skips linking at all. Since most GWT users these days download from Maven Central, this means the extra help is missing.
  • DevMode logs a link to https://github.com/gwtproject/gwt/blob/main/distro-source/core/src/doc/helpInfo/servletMappings.html with level DEBUG, so that if an error/warning happens when examining those tags, the user will have a helpful link to review. This document is very out of date.
  • JettyLauncher logs a link to https://github.com/gwtproject/gwt/blob/main/distro-source/core/src/doc/helpInfo/webAppClassPath.html when something wasn't in WEB-INF/lib that was accessed by something on the server classpath. Again, somewhat out of date (though less egregiously), but probably accurate enough to finish deprecating JettyLauncher until it is outside of gwt-dev itself.
  • JSORestrictionsChecker logs a link to https://github.com/gwtproject/gwt/blob/main/distro-source/core/src/doc/helpInfo/webAppClassPath.html for any failed restriction. This could easily be adapted to a section on https://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html or a related page.
  • JsniReferenceResolver logs a link to https://github.com/gwtproject/gwt/blob/main/distro-source/core/src/doc/helpInfo/webAppClassPath.html when a long value is accessible from JS. Again, could end up in the JSNI docs or a related page.
• The only other link that exists is from BrowserChannelServer, to http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM (code.google.com is erroring out, so it apepars to be a dead link at this time). This would only be logged for an old browser plugin to a "recent" legacy dev mode server instance as a warning - probably can be safely removed.

Past releases had at least one other:

• If GWT was found to be out of date, a link to release notes... with a null URL.

Proposed steps:

• Create a directory specifically for "gwt-dev-help" in gwt-site, and create files there for help options as they are updated/created. Consider adding an anchor or queryparam including the GWT version, so that an anchor/etc can be added to the page with specifics for older versions (as the website might get updates as features change/improve) - this is the sort of feature we can't go back and add later when it matters.
• Deprecate and replace InstalledHelpInfo with "GwtprojectHelpInfo".
• Migrate and update existing help text documents, fixing details that are no longer helpful, adding references to other pages.
• Consider adding new documents, dealing with jsinterop, regressions, reporting bugs when they are found, etc.