Really need help getting CodeServer to run with Java 11 and GWT 2.10

[Mathias]

I really could use some help getting my project up for development after moving to gwt 2.10 and Java 11.
I can unfortunately nolonger use the GWT intellij plugin i've loved and used for 12 years apparently, and i'm struggling a bit to get the codeserver running for my project.

CURRENT STATUS:
My project is over 12 years, but i migrated it from the old gwt mojo plugin to the new tbroyer one last year.
It builds into a war fine and deploys on tomcat. Prior to the migration to GWT 2.10 (with new Jetty) and Java 11, i could run it with the GWT Intellij plugin, which I've loved and used for those same 12 years. 

But now the plugin unfortunately doesn't work, and from what I can tell due to the JettyLauncher, (I get lots of classnotfounds for for example javax.sql.DataSource)  it's kind of impossible to make it run? So I thought I'd try what people have been saying, move to the manual thing with server and code server, even though it's a more cumbersome setup.

As part of trying to get this show on the road, i created an archetype project and got codeserver and server running according to the new v2 tutorial. This works fine.

PROBLEM:
Basically i can't get the codeserver to run. My project is pretty large so my "webclient" module that contains my gwt client has a bunch of dependencies on my own child modules, and a couple of third-party ones such as Lombok.


When i try the codeserver with this command (from the tutorial)
 mvn gwt:codeserver -pl webclient -am

,where the webclient is the module containing the gwt code and entry point, standing in the root dir of my project,
,i get page up and page down filled with missing dependencies from stuff and "did you forget to inherit"-errors. (see error extract at the bottom)

-I'm not sure if this has something to do with the "workdir", the directory i stand in when i try to start the codeserver as described above, some dependency declaration i'm missing or something else.

-My dependencies should be ok since i can build it with the plugin, so i'm a bit at a loss as to how make this work.

-Help would be much appreciated, right now i can't develop and rolling our project back to 2.8 and Java 8 wouldn't be great and take time. Man how I wish that the intellij plugin had just kept working.

as a final aside:
The "neither a gwt-lib or jar" warning messages in the error log below - i still get it if i add the gwt-lib type to the dependency, and the archetype project prints the same error when created.

Extract from the error log:

[INFO] Ignoring com.myproject:generalcommons:jar:1.0-SNAPSHOT; neither a gwt-lib or jar:sources; Did you forget to use <type>gwt-lib</type> in the dependency declaration?
[INFO] Ignoring com.myproject:webshared:jar:1.0-SNAPSHOT; neither a gwt-lib or jar:sources; Did you forget to use <type>gwt-lib</type> in the dependency declaration?
[INFO] Ignoring com.myproject:webmaps:jar:1.0-SNAPSHOT; neither a gwt-lib or jar:sources; Did you forget to use <type>gwt-lib</type> in the dependency declaration?
[INFO] Ignoring com.myproject:webshared:jar:1.0-SNAPSHOT; neither a gwt-lib or jar:sources; Did you forget to use <type>gwt-lib</type> in the dependency declaration?
[INFO] Turning off precompile in incremental mode.
[INFO] Super Dev Mode starting up
[INFO]    workDir: /Users/mathias/.projects/myproject/target/gwt/codeserver
[INFO]    [WARN] Deactivated PrecompressLinker
[INFO] 19:00:51.710 [main] INFO org.eclipse.jetty.util.log - Logging initialized @778ms to org.eclipse.jetty.util.log.Slf4jLog
[INFO] 19:00:51.714 [main] DEBUG org.eclipse.jetty.http.PreEncodedHttpField - HttpField encoders loaded: [org.eclipse.jetty.http.Http1FieldPreEncoder]
[INFO]    Loading Java files in com.myproject.client.
[INFO]    Tracing compile failure path for type 'com.myproject.client.domain.group.GroupDragDropLayout'
[INFO]       [ERROR] Errors in 'file:/Users/mathias/.projects/myproject/webgwtcommons/src/main/java/com/myproject/client/domain/group/GroupDragDropLayout.java'
[INFO]          [ERROR] Line 18: The import lombok cannot be resolved
[INFO]          [ERROR] Line 7: The import com.myproject.common cannot be resolved
[INFO]          [ERROR] Line 32: Getter cannot be resolved to a type
[INFO]          [ERROR] Line 114: CSConstants cannot be resolved to a variable
[INFO]    Tracing compile failure path for type 'com.google.gwt.validation.client.impl.ConstraintFinderImpl'
[INFO]       [ERROR] Errors in 'jar:file:/Users/mathias/.m2/repository/org/gwtproject/gwt-user/2.10.0/gwt-user-2.10.0.jar!/com/google/gwt/validation/client/impl/ConstraintFinderImpl.java'
[INFO]          [ERROR] Line 38: No source code is available for type javax.validation.metadata.ElementDescriptor.ConstraintFinder; did you forget to inherit a required module?
[INFO]          [ERROR] Line 70: No source code is available for type javax.validation.metadata.ConstraintDescriptor<T>; did you forget to inherit a required module?
[INFO]          [ERROR] Line 99: No source code is available for type javax.validation.groups.Default; did you forget to inherit a required module?
[INFO]          [ERROR] Line 88: No source code is available for type javax.validation.metadata.Scope; did you forget to inherit a required module?
[INFO]       [ERROR] Errors in 'jar:file:/Users/mathias/.m2/repository/org/gwtproject/gwt-user/2.10.0/gwt-user-2.10.0.jar!/com/google/gwt/validation/client/impl/metadata/BeanMetadata.java'

[Jens]

A full example for multiple maven modules (more than just three) can be found here: https://github.com/tbroyer/gwt-maven-plugin/tree/main/src/it/e2e

You have to add <packaging>gwt-lib</packaging> to your own maven library modules that contain a module.gwt.xml file. Maybe you forgot that?

-- J.

[Thomas Broyer]

On Friday, April 12, 2024 at 7:50:42 AM UTC+2 Mathias wrote:

-My dependencies should be ok since i can build it with the plugin, so i'm a bit at a loss as to how make this work.

Dependencies for gwt:compile and gwt:codeserver aren't the same: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html

You might have to either adjust the <scope> of dependencies (e.g. from provided to compile) or adjust the gwt:codeserver's classpathScope (e.g. from runtime to compile+runtime or compile)

 

as a final aside:
The "neither a gwt-lib or jar" warning messages in the error log below - i still get it if i add the gwt-lib type to the dependency, and the archetype project prints the same error when created.

Note that it's an info, not a warning 😉

[Mathias]

Fair enough mate, I just remarked on it since when I built the archetype from scratch and saw that, my first thought was "huh wonder why that is, surely it won't work now since it doesn't pull in the classes from shared", but it did :) 

[Mathias]

Hey Jens, thanks for replying!

re. the gwt-type:

1. I only have one maven module that contains the entry point. the "gwt client" module

2. All dependencies are either on third-party such as Lombok, or my own other modules that only contain java classes and are built as jar-files.

3. I added the "type" gwt-lib to the dependencies in the "gwt client" pom, but I didn't do anything to the pom files in the jar modules that the gwt client depend on. I mean, Lombok doesn't have a packaging <packaging>gwt-lib</packaging> in its pom, either. 

[Marco Tenti (IoProgrammo88)]

This project has many good examples to check out https://github.com/NaluKit/nalu-examples, it help me a lot.

[Mathias]

Thanks! That's a great resource and got me to see one thing I'd missed.

[Mathias]

Thomas, Marco showed me a project that made me see one thing I hadn't thought about, which was configured the same in the archetype project. It's regarding the sources.

In my project, I only have one jar that contain both classes and source files for those jar files that are needed, i.e. no sources-jar anywhere. This was a long time ago, but I think it was because we also needed to include things like .properties-files for i18n which are in submodules as well, so we use the <resources> tags to define them.

In any case - this apparently works fine for the compile, but could this be a reason for CodeServer not finding the class files? On the other hand, it doesn't find Lombok either which worked before, and I don't have any lombok sources.jar in my repo. Perhaps it doesn't need the Lombok sources since it's just annotations? 

On Friday 12 April 2024 at 11:20:01 UTC+2 Thomas Broyer wrote:

[Mathias]

Hi Thomas

unfortunately, I'm still stuck. I thought I'd attack the Lombok dependency first, since that's a third-party it depends on. I don't suppose you've ever been exposed to that? 

I tried setting the 

<classpathScope>compile</classpathScope> to the "configuration" setting of the plugin def in pluginmanagement of the root pom. That didn't help. (neither compile+runtime)

In the intellij GWT-plugin I got it working while running by setting the argument "-javaagent:/...path..../lombok-1.16.14.jar=ECJ , not sure if that could change anything. I mean this breaks at compile so I don't know.

I have gone through the configuration line-by line with both your archetype project and the NaluKit Marco tipped me about. I can't see any relevant difference. I don't have <type>gwt-lib</type> on any dependency, but neither does any of the other projects I look at.

I also tried adding lombok dependency to the plugin, it didn't help either.

I am basically stuck, this is not great. Would you have time to look at the plugin config if I pasted it?

On Friday 12 April 2024 at 11:20:01 UTC+2 Thomas Broyer wrote:

[RobW]

Note sure if this will gelp you much - we're a Gradle user, and don't use intellij. But the basic principles are the same.

When we migrated to the latest GWT we also updated our top level gradle build file to have a gwtSuperDev task which does all the heavy lifting for us:

    task gwtSuperDev(dependsOn: 'build') {
        // probably a nicer way of getting these (e.g through project sourcepaths)
        def gwtapi_src = file('tas/gwtapi/src')
        def webui_src = file('webui/src')

        doLast {
            def compilerArgs = [
                        "-strict", "-noincremental", "-noprecompile",
                        "-src", "${gwtapi_src}/",
                        "-src", "${webui_src}/",
                        "com.ascert.webui.vt.VtWebUi-dev"
                        ]

            javaexec {
                main = 'com.google.gwt.dev.codeserver.CodeServer'
                // Leverage the Gradle create classpaths for gwtapi and webui subprojects
                // Make sure GWT build libs are at the front to ensure the vanilla GWT jetty classes are used by codeserver
                classpath += configurations.gwtBuild
                // These classpaths will duplicate some of the above, but doing this way ensures our custom jetty does not get
                // picked up by GWT codeserver, which causes class inconsistencies.
                classpath += project(':proj:webui').configurations.compileClasspath
                classpath += project(':proj:tas:gwtapi').configurations.compileClasspath

                maxHeapSize = "1000m"

                args = compilerArgs.flatten()
            }
        }
    }

Our 2 main source trees are defined by gwtapi_src and webui_src. The com.ascert.webui.vt.VtWebUi-dev is our dev GWT XML file name. It's slightly different to our prod one as it has debug flags on and only creates a single large permutation.

That's really the main part. We also have the source modules on the classpath as :proj:webui and :proj:gwtapi - for reasons as per the comments.

The only other crucial part is the configurations.gwtBuild. This is a gradle configuration with all the JARs needed for codeserver (gwt_dev, gwt_user, various js lib jars such as GXT etc.). It's really just a convenient way of handling classpath JARs and nothing more. If/when we update the versions of any of those, the above automatically pulls in the updated dependency versions.

There's really nothing that special about CodeServer apart from making sure all your own sources and JARs are on the classpath, plus the standard GWT ones and any 3rd party libs you use. Although the above is for Gradle, the same principles and approach ought to apply for MVN or any other build tool.

Good luck!

-Rob