Asking for decision on DevMode embedded Jetty support

315 views
Skip to first unread message

Jens

unread,
Apr 11, 2021, 11:15:34 AMApr 11
to GWT Contributors
Hi,

we all know the issue: DevMode bundles Jetty and people are using it even though we do not recommend it. Consequently people are complaining that bundled Jetty is too old. So every once in a while we upgrade it.

Currently with GWT 2.9.0 the situation is:
- GWT SDK is compiled to Java 7 byte code
- GWT Compiler requires ASM 7.x to support Java 11
- DevMode bundles Jetty 9.2 which uses ASM 5.x
- gwt-dev.jar can only bundle a single Jetty, since we do not relocate it. However there is already a question asking for Jakarta Servlet support, e.g. Jetty 11 / Tomcat 10.

Currently the ASM version misalignment between Jetty 9.2 and GWT compiler causes classpath issues. This could be fixed by upgrading to Jetty 9.4 and consequently compiling GWT SDK to Java 8 byte code as that is a requirement for Jetty 9.4.

However given the new Jakarta namespace and first questions about supporting it, I am wondering if it wouldn't be wiser to remove embedded Jetty from DevMode now, invest some work to make GWT-RPC and RequestFactory useable with old javax.servlet and new jakarta.servlet namespaces and finally cut a 2.10 or 3.0 release given the removal of embedded Jetty.

Personally I would strongly vote for removal because GWT nowadays is in maintenance mode with only very few changes here and there to support J2CL better. Even reviews from contributors are rare these days I guess. Every action we take nowadays should take maintenance effort into account and a low maintenance effort is obviously preferred. If we upgrade Jetty to 9.4 we still have that Jakarta issue coming up more often in the future for sure.

Generally this would be a decision made by GWT steering group but I have no idea if this group still exists. So I am asking here for a decision how to move on.

-- J.

Jens

unread,
Apr 11, 2021, 5:04:13 PMApr 11
to GWT Contributors
For reference:

Jetty ASM issues:

Jakarta servlet support question:

Other embedded Jetty related issues:
jrt: URLs not recognised with Java 9+: https://github.com/gwtproject/gwt/issues/9582
Class loader leak protection code causes (ignorable, yet annoying) error logs in Java 9+: https://github.com/gwtproject/gwt/issues/9561




Frank Hossfeld

unread,
Apr 13, 2021, 11:16:51 AMApr 13
to GWT Contributors
I agree with Jens. I would - also - vote for the removal. 

Besides the things Jens mentioned, we have Thomas Broyer's gwt-maven-archetype (for Jetty/Tomcat) or the gwt-maven-springboot-archetype (for Spring Boot) to generate Maven multi module projects. So, it is quite easy to generate a multi module project. And it is well documented and maintained.

 I would prefer spending some times on updating gwtproject.org (the part of how to start) instead of udpating the Jetty stuff.

I know, that there are many single module projects outside that run with devmode. I moved sereval of them to a new project structure inn the last years. In many cases this is not really hard to do. 

eliasb...@gmail.com

unread,
Apr 13, 2021, 12:18:21 PMApr 13
to GWT Contributors
Removal of embedded Jetty from DevMode sounds sensible and I would normally agree.

However, I am working as an architect for a global organization with many projects build on GWT and our development process relies heavily on DevMode and embedded Jetty.

Removing embedded Jetty will make the work for our developers more difficult because they will have to perform at least 5 steps to run our applications on their PCs compared to just 1 at the moment.
This is going to raise quite a few eyebrows across the enterprise and decrease the productivity of our developers.

I also expect that we are not only the only organisation with GWT codebases and other teams equally rely on DevMode and embedded Jetty..

I vote for removal of support for Java7 and adjustment of the GWT classpath to align with embedded Jetty classpath, under GWT 2.9.0 and so forth in the future.

Please don't force us to change our ways unnecessarily.

Richi Plana

unread,
Apr 13, 2021, 2:01:04 PMApr 13
to google-web-tool...@googlegroups.com

As a user and non-contributor, I would vote for bumping up versions (Java 7 to 8, Jetty to 9.4). The move to Java 8 is something I would have to do if I had any Java 7 projects left. And Jetty has lots of used features that I'm not hearing proposals for replacement for.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/622544a8-85d5-41c5-b8da-7a733667eb89n%40googlegroups.com.

Thomas Broyer

unread,
Apr 13, 2021, 2:04:04 PMApr 13
to Google Web Toolkit Contributors
Which features are you talking about? Which would you lose by switching to using a *real* Jetty server alongside GWT CodeServer?

Frank Hossfeld

unread,
Apr 13, 2021, 2:19:23 PMApr 13
to GWT Contributors
@eliasbalasis: Why you need 5 steps to run the application in a GWT multi module project? I have two runnning configuration, one for the code server another for the server. I, personally, prefer Spring boot. Starts very fast! And, if you running your app in the cloud, Spring Boot is awesome.

Manfred Tremmel

unread,
Apr 13, 2021, 2:36:38 PMApr 13
to google-web-tool...@googlegroups.com, Jens
- my libraries all require Java 8 (gwt-bean-validators is based on hibernate-
validator 6.1.7, which requires Java 8, gwt-commons-lang3 is based on apache
commons-lang3 3.12.0 which requires Java 8 and each other project depends on
gwt-commons-lang3)
- all my applications are migrated to Java 11

So kicking Java 7 support would be no problem for me.

Get rid of imported Jetty would make security checks easier, the owasp
dependency-check suppression list in gwt projects is always so long.


eliasb...@gmail.com

unread,
Apr 13, 2021, 2:42:54 PMApr 13
to GWT Contributors
Our developers are using "Google Plugin for Eclipse" from which they can start DevMode for any of our GWT application with a single step.

If we wanted to use a CodeServer we would have to perform more steps. e.g. compile the code, start a server manually, deploy the app to the server, start the code server, start a browser then point the browser to the code server etc.

I am hoping that the difference is obvious.

For our enterprise this is going to be a major shift and obviously we are not happy having to change our ways.

eliasb...@gmail.com

unread,
Apr 13, 2021, 2:45:22 PMApr 13
to GWT Contributors
And yes we are packaging GWT apps as SpringBoot

Richi Plana

unread,
Apr 13, 2021, 3:01:43 PMApr 13
to google-web-tool...@googlegroups.com
I should've been more explicit. The feature of having a self-contained app server for pure gwt frontend development (for dev purposes). My understanding is that it's a choice of bumping up Java version or losing Jetty. 

Message has been deleted

eliasb...@gmail.com

unread,
Apr 13, 2021, 3:07:02 PMApr 13
to GWT Contributors
Indeed.

It seems that bumping up Java is desirable or tolerable.

However, we cannot compromise with losing Jetty.

Thomas Broyer

unread,
Apr 13, 2021, 3:11:05 PMApr 13
to Google Web Toolkit Contributors


Le mar. 13 avr. 2021 à 20:42, eliasb...@gmail.com <eliasb...@gmail.com> a écrit :
Our developers are using "Google Plugin for Eclipse" from which they can start DevMode for any of our GWT application with a single step.

If we wanted to use a CodeServer we would have to perform more steps. e.g. compile the code, start a server manually, deploy the app to the server, start the code server, start a browser then point the browser to the code server etc.

I am hoping that the difference is obvious.

(I never used this, just know that it exists)

Automating those tasks through your build tool (Maven, Gradle, whatever), when possible, makes it only 2 clicks / commands (ok, maybe 3 to open the app in the browser), and doesn't lock you into one IDE with an unmaintained plugin.

At some point you'll have to invest one way or another to move forward (could be investing in maintaining GWT too)

Thomas Broyer

unread,
Apr 13, 2021, 3:14:16 PMApr 13
to Google Web Toolkit Contributors
What do you mean by "pure GWT frontend" ? Do you need servlets ? Or serving only static files would be OK?
Because the problem is with server side code.

eliasb...@gmail.com

unread,
Apr 13, 2021, 3:18:44 PMApr 13
to GWT Contributors
I would happily invest in maintaining GWT to support my teams if I have to.

eliasb...@gmail.com

unread,
Apr 13, 2021, 3:23:47 PMApr 13
to GWT Contributors
This is something I have been pushing my teams to do.

We keep out GWT apps very simple, just "CRUD" so that they can run in DevMode but also de-couple from business logic and background tasks as much as possible, a microservices approach.

If that is not enough we equip the GWT app strictly with front-end code, we keep the back-end services in a separate application and bridge the two with a remote API (e.g. REST+JSON).

I believe this is what is implied by "pure GWT frontend"

Peter Donald

unread,
Apr 13, 2021, 8:42:04 PMApr 13
to google-web-tool...@googlegroups.com
On Wed, Apr 14, 2021 at 5:23 AM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
This is something I have been pushing my teams to do.

We keep out GWT apps very simple, just "CRUD" so that they can run in DevMode but also de-couple from business logic and background tasks as much as possible, a microservices approach.

If that is not enough we equip the GWT app strictly with front-end code, we keep the back-end services in a separate application and bridge the two with a remote API (e.g. REST+JSON).

I believe this is what is implied by "pure GWT frontend"

On Tuesday, 13 April 2021 at 20:14:16 UTC+1 t.br...@gmail.com wrote:
What do you mean by "pure GWT frontend" ? Do you need servlets ? Or serving only static files would be OK?
Because the problem is with server side code.

One thing you may want to consider is actually publishing all resources as "<public/>" assets in your gwt modules. That way you can sneakily use the codeserver to host your launcher page and everything else and only need the codeserver. As long as you don't not have massive numbers of local assets or large size it works quite well. In short we put the launcher html inside public and use the "/recompile-requester/mygwtmodule" as the url for the js code.

So in a typical GWT only microservice frontend we end up with 3 GWT modules (1 common, 1 for local development and 1 for production) that declare 1 public dir each. In each public dir is the appropriate assets (common assets in common public dir, dev launcher in development public dir, production launcher in production public dir). Then you can just start local code server and run the app from in it ;)

For example:



Often we can just use these as is but sometimes we do put a proxy in it (when they use host relative services/links/whatnot, SSL or other capabilities). Seems to work fine for us ;)

--
Cheers,

Peter Donald

eliasb...@gmail.com

unread,
Apr 14, 2021, 3:44:34 AMApr 14
to GWT Contributors
>> As a user and non-contributor, I would vote for bumping up versions (Java 7 to 8, Jetty to 9.4). The move to Java 8 is something I would have to do if I had any Java 7 projects left. And Jetty has lots of used features that I'm not hearing proposals for replacement for.

I couldn't agree more.
Losing support for Java 7 is both tolerable and desirable.
Losing support for embedded Jetty is not acceptable, not without a replacement which wasn't proposed.

JonL

unread,
Apr 14, 2021, 10:05:25 AMApr 14
to GWT Contributors
As a developer of various GWT apps large and small, I personally would like to see the Jetty support separated and modularized but maintained. The embedded Jetty support allows for a simple start to new projects where you can focus on getting started on development vs getting setup.  This reduction of friction was a big selling point in our initial usage of GWT.  The problem with dropping the embedded Jetty support isn't just removing it, most of the documentation on the gwtproject.org revolves around using it.  There is little or no documentation about setting up to not use it, so I think that would need to be one of the first things that would have to be done is provide examples for various IDEs, build tools and run scenarios before it were dropped.

Ultimately though, modularizing and separating it into it's own project would hopefully incentivize the community and especially IDE plugin authors to expand it and keep it up to date.

Richi Plana

unread,
Apr 14, 2021, 10:37:48 AMApr 14
to google-web-tool...@googlegroups.com

Paul Robinson

unread,
Apr 15, 2021, 2:56:43 AMApr 15
to google-web-tool...@googlegroups.com
I used the built in Jetty server until a year or so ago. Occasionally I have to use the older version in development as we haven't upgraded everybody in production to the new version yet.

From a development perspective, I find running a separate code server and Jetty to be much more productive.

Whenever I need to restart, it's usually only Jetty I need to restart, and it's much faster to not restart the code server part as well.

So there may be an extra step, but I'm much happier with it this way.

Paul

Vassilis Virvilis

unread,
Apr 15, 2021, 3:12:40 AMApr 15
to google-web-tool...@googlegroups.com
Paul,

What about the bookmarklet?. Is out working in your setup?

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

Michael Conrad

unread,
Apr 15, 2021, 9:04:15 AMApr 15
to google-web-tool...@googlegroups.com, Jason Carter
How would this impact Super Dev Mode in Gradle?

We use Gradle with 'org.wisepersist:gwt-gradle-plugin:1.1.8'.

Thomas Broyer

unread,
Apr 15, 2021, 10:07:49 AMApr 15
to Google Web Toolkit Contributors, Jason Carter
If you use the gwtSuperDev task, or if you use the gwtDev task but set noserver=true, then it won't impact you. You're then already starting another web server to serve your server-side code (and your host page).
If you use the gwtDev task and did not set noserver=true, then you'd have to move to gwtSuperDev and a separate server (e.g. through the Gretty plugin); or move to the de.ecoso.gwt plugin which does not use DevMode yet provides a single task that starts both CodeServer and a separate Jetty server: https://github.com/esoco/gwt-gradle-plugin

You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e226962d-8433-2e7a-9622-353baddea646%40newsrx.com.


--
Thomas Broyer
/tɔ.ma.bʁwa.je/

Michael Conrad

unread,
Apr 15, 2021, 6:08:53 PMApr 15
to google-web-tool...@googlegroups.com
Ok,

Sounds like we wouldn't be affected, we always run our stuff via TomCat with a one liner using the gretty Gradle plugin.

-Mike

Vassilis Virvilis

unread,
Apr 16, 2021, 8:15:14 AMApr 16
to google-web-tool...@googlegroups.com
Hi,

When I am running SuperDevMode I am getting the message below. I couldn't help but notice a lot of jetty references there and I need to ask.

What will a hypothetical jetty removal affect?:
a) Old Dev mode with browser plugin requires Firefox 24 workflow
b) New Super Dev Mode codeserver - bookmarklet workflow

If it is a) only then I have a problem removing jetty.
If it is a) + b) please don't remove jetty.

If the removal of jetty will affect b) is there any way to achieve the same functionality that the bookmarklet has with existing technology and not with future unreleased software (j2cl)? I don't mind extra steps. I can script them. I do mind extra clicks though...

Maybe the answer is in the reply Peter gave above. But to me it looks like the codeserver depends on jetty.

Please correct me If I am wrong.
Thanks in advance.

Turning off precompile in incremental mode.
Super Dev Mode starting up
  workDir: /tmp/gwt-codeserver-9653028892487452430.tmp
INFO 2021-04-13 16:58:39,183 main: org.eclipse.jetty.util.log.Log.initialized(Log.java:186): Logging initialized @1755ms
  Loading Java files in com.xxx.yyy.zzz
  Ignored 13 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
  Module setup completed in 17254 ms
INFO 2021-04-13 16:58:55,404 main: org.eclipse.jetty.server.Server.doStart(Server.java:327): jetty-9.2.z-SNAPSHOT
INFO 2021-04-13 16:58:55,500 main: org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:744): Started o.e.j.s.ServletContextHandler@36c025a0{/,null,AVAILABLE}
INFO 2021-04-13 16:58:55,532 main: org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:266): Started ServerConnector@7d5c7af5{HTTP/1.1}{127.0.0.1:9876}
INFO 2021-04-13 16:58:55,538 main: org.eclipse.jetty.server.Server.doStart(Server.java:379): Started @18111ms

The code server is ready at http://127.0.0.1:9876/
....



--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.


--
Vassilis Virvilis

Paul Robinson

unread,
Apr 16, 2021, 8:46:38 AMApr 16
to google-web-tool...@googlegroups.com
Vassilis - I don't use the bookmarklet. It may still work (I don't know) but it's not needed in recent GWT versions. I just refresh my browser and it recompiles automatically if anything has changed.

Paul

Vassilis Virvilis

unread,
Apr 16, 2021, 9:12:08 AMApr 16
to google-web-tool...@googlegroups.com
That's great news to hear. Is there any doc about this?

How does it know when to switch between codeserver and production code?

On Fri, Apr 16, 2021, 15:46 Paul Robinson <ukcu...@gmail.com> wrote:
Vassilis - I don't use the bookmarklet. It may still work (I don't know) but it's not needed in recent GWT versions. I just refresh my browser and it recompiles automatically if anything has changed.

Paul

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

Thomas Broyer

unread,
Apr 16, 2021, 11:07:28 AMApr 16
to Google Web Toolkit Contributors
On Fri, Apr 16, 2021 at 3:12 PM Vassilis Virvilis <vas...@gmail.com> wrote:
That's great news to hear. Is there any doc about this?

It's been there since 2.7, *checks notes* more than 6 years ago.
Either pass `-launcherDir` to CodeServer, or use DevMode, which defaults to using that (legacy DevMode has to be explicitly reenabled through -nosuperDevMode)
 
How does it know when to switch between codeserver and production code?

A stub nocache.js file is generated (overwriting your production one if you use the same dir) that will trigger a recompile on the CodeServer and load the generated script, similar to clicking the bookmarklet.

What we're talking about here is more or less about removing DevMode "as we know it" that directly serves a web app following the "exploded WAR" layout, and only keeping the CodeServer; or possibly serve static files from DevMode but no longer host servlets et al.
The issue here is conflicts between Jetty/DevMode and the project's server-side dependencies in the classpath (due to a project with mixed client and server code, and the fact that we have a custom WebAppClassLoader that loads from both the WEB-INF/classes+WEB-INF/lib and the classpath), and even conflicts between Jetty and the WEB-INF/lib, and of course issues with the version of ASM from GWT used by Jetty to scan the webapp classloader when it encounters module-info.class files.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

Vassilis Virvilis

unread,
Apr 16, 2021, 3:27:24 PMApr 16
to google-web-tool...@googlegroups.com
Thomas,

Thanks for the writeup. This clears the things a bit.

I had already understood the reasons you want to get rid of jetty.

What I hadn't understood was the term DevMode was not referring to the legacy plugin based mode. Hm... Let's remove the double negatives.
I believed that DevMode was referring to the legacy plugin mode (port 8888).

To my defense the documentation needs a bit of love. The old devmode is very prominent in google searches. It is under Docs/Coding Basics/Compile & Debug
http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html and the http://www.gwtproject.org/articles/superdevmode.html mentions -launcherDir in soup of options and text. It needs some formatting there. Furthermore it mentions the bookmarklet as the suggested way of compiling.

So AFAIKT assuming I don't use servlets if jetty is removed I will run the codeserver locally (localhost) and we will export its output (nocache.js ) with the server that I choose such as jetty, apache, tomcat nginx whatever. The capability to debug live production sites with dev_mode_on.js (with the bookmarklet or other similar means) will be unaffected because (now I get it) it has nothing to do with the codeserver. dev_mode_on.js overrides/rewrites from where we are loading the nocache.js script.

Sorry for the trouble and thanks for the explanations.

   Vassilis

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.


--
Vassilis Virvilis

eliasb...@gmail.com

unread,
Apr 17, 2021, 7:00:51 AMApr 17
to GWT Contributors
I am grabbing the opportunity to summarize by emphasizing the following:

1.
IMO DevMode+Jetty should NOT be removed because it is still being is use, particularly by enterprise teams.

2.
DevMode+Jetty has always been a very good selling point for GWT since its birth.
If you want to remove DevMode+Jetty you have to provide a replacement and I have only read about removal so far.

4.
Removal of support for Java 7 is more than welcome and tolerable it seems as it is not being used by projects anymore.
Also projects that are still using Java7 should move to Java8+ regardless.

5.
I accept that people still using DevMode+Jetty , like teams in the enterprise I work for, may have to consider a transformation in the future as soon as we reach a dead end,
but not just yet.

6.
Considering, all of the above.
I suggest dropping Java7 support, aligning the GWT classpath with Jetty classpath and keep doing so until we reach a dead end, then we can consider making any kind of disruptive changes (like replacing DevMode+Jetty).
Until then we shouldn't be forced to change our ways unnecessarily.

Bernhard Schulz

unread,
Apr 17, 2021, 9:58:37 AMApr 17
to google-web-tool...@googlegroups.com
Hi all!

I don’t get this particular statement:
Until then we shouldn't be forced to change our ways unnecessarily.

This is not limited to eliasb...@gmail.com ’s last email but to many comments here on this list/group.

Nobody is forced to change any way.

In my opinion:
Just stick to the current version of GWT and the toolchain you use at the moment. 

But for future releases, be it GWT 3.0, GWT 2.10, GWT 2.9.x, J2CL or whatever you call it, let’s drop the support for old/outdated/„cumbersome“ technologies/versions/products etc. so that all the other developers can use modern tools and the guys who maintain/develop GWT and all the other plugins/IDEs/tools in this ecosystem for us do not have to bother about this old stuff. Let’s move forward!!

Don’t get me wrong, I really understand that many enterprises maintain big GWT applications which are running for many years now and will run for many more and these have to be supported.
But nobody takes the existing tools away. Just stick to the current version and you are good.

Just my 50 cent, without - hopefully - annoying someone.

Thank you!




On Friday, 16 April 2021 at 16:07:28 UTC+1 t.br...@gmail.com wrote:
On Fri, Apr 16, 2021 at 3:12 PM Vassilis Virvilis <vas...@gmail.com> wrote:
That's great news to hear. Is there any doc about this?

It's been there since 2.7, *checks notes* more than 6 years ago.
Either pass `-launcherDir` to CodeServer, or use DevMode, which defaults to using that (legacy DevMode has to be explicitly reenabled through -nosuperDevMode)
 
How does it know when to switch between codeserver and production code?

A stub nocache.js file is generated (overwriting your production one if you use the same dir) that will trigger a recompile on the CodeServer and load the generated script, similar to clicking the bookmarklet.

What we're talking about here is more or less about removing DevMode "as we know it" that directly serves a web app following the "exploded WAR" layout, and only keeping the CodeServer; or possibly serve static files from DevMode but no longer host servlets et al.
The issue here is conflicts between Jetty/DevMode and the project's server-side dependencies in the classpath (due to a project with mixed client and server code, and the fact that we have a custom WebAppClassLoader that loads from both the WEB-INF/classes+WEB-INF/lib and the classpath), and even conflicts between Jetty and the WEB-INF/lib, and of course issues with the version of ASM from GWT used by Jetty to scan the webapp classloader when it encounters module-info.class files.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

--
schubec GmbH
DI (FH) DI Bernhard Schulz
Dreifaltigkeitsgasse 18
5020 Salzburg
Austria / EUROPE

Tel:  +43 699 19337476
Mail: bernhar...@schubec.com
URL:  https://www.schubec.com
Skype-Username: schubec

Geschäftsführer der schubec GmbH: DI (FH) DI Bernhard Schulz
Sitz der Gesellschaft: 5020 Salzburg
Firmenbuchnummer: FN383758a
Steuernummer: 1584886
UStID: ATU67395366

Impressum:
https://www.schubec.com/de/impressum.php

eliasb...@gmail.com

unread,
Apr 17, 2021, 10:51:32 AMApr 17
to GWT Contributors
Well said.

Allow me to explain what I meant by saying "we shouldn't be forced to change our ways unnecessarily."

Following past discussions and the current conversation,
I felt that there is a push by certain people towards removing Jetty support from GWT to ease the maintenance pains and without replacing it with something equivalent.
This is going to be disruptive for the teams in the organization I work for and probably many other teams worldwide.

I expect the current technology to be preserved the way it is so that we can keep following our current development recipes without disruption or productivity impact.

This implies IMO that Java7 support has to be dropped and the GWT classpath has to be aligned and kept being aligned going forward with that of a more recent Jetty version, until such time that we reach a dead end and this construct cannot be maintained anymore.

Paul Robinson

unread,
Apr 17, 2021, 12:25:19 PMApr 17
to google-web-tool...@googlegroups.com
Would it be plausible to split GWT into two projects - one as it is now but without Jetty built in, and another that adds the bits relating to Jetty?

Then the GWT Jetty project could be maintained by those that require it.

Paul

eliasb...@gmail.com

unread,
Apr 17, 2021, 1:34:19 PMApr 17
to GWT Contributors
This is a very good idea.

I am afraid though that it wouldn't change the situation much because the classpaths of GWT and Jetty co-exist and must be aligned regardless.

But, I would stand corrected.

Thomas Broyer

unread,
Apr 17, 2021, 1:45:39 PMApr 17
to Google Web Toolkit Contributors
Moreover, we have to be careful when we say "remove Jetty", because Jetty is used in CodeServer and JUnitShell.
Really the question here is about removing the ability to serve webapps, with servlets, from DevMode.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

eliasb...@gmail.com

unread,
Apr 17, 2021, 2:06:49 PMApr 17
to GWT Contributors
This feels much better now.

Serving only static GWT client-side via DevMode+Jetty sounds good.

We could run the GWT server-side only code separately, not a problem at all.

But, how would the GWT client-side know how to access GWT server-side?

Thomas Broyer

unread,
Apr 17, 2021, 2:36:18 PMApr 17
to Google Web Toolkit Contributors
If it's not a problem for you to serve servlets separately, could you explain why you couldn't have this other server also serve the host page and nocache.js file? Is that due to, maybe, how your projects are structured? (Could you give more details then?)
Trying to understand what's blocking people here.

eliasb...@gmail.com

unread,
Apr 17, 2021, 2:45:35 PMApr 17
to GWT Contributors
During development,
with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse",
GWT client-side code compilation (including the nocache.js files) is done at runtime by DevMode.

Any other scenario demands that we,
separately compile the GWT client-side code,
separately run a servlet,
separately deploy the GWT code to the server (both client-side and server-side),
separately run GWT CodeServer,
then run a browser,
then genearate the CodeServer link etc.

The complexity difference is obvious.

I hope this explains my case.

Thomas Broyer

unread,
Apr 17, 2021, 3:03:37 PMApr 17
to Google Web Toolkit Contributors



Le sam. 17 avr. 2021 à 20:45, eliasb...@gmail.com <eliasb...@gmail.com> a écrit :
During development,
with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse",
GWT client-side code compilation (including the nocache.js files) is done at runtime by DevMode.

Same with CodeServer with -launcherDir, or DevMode with -noserver.

Any other scenario demands that we,
separately compile the GWT client-side code,
separately run a servlet,
separately deploy the GWT code to the server (both client-side and server-side),
separately run GWT CodeServer,
then run a browser,
then genearate the CodeServer link etc.

The complexity difference is obvious.

What would be the workflow with DevMode serving only static files, and servlets deployed separately?
(then I'll tell you how the above could be; there's ONE requisite though: that your server where you serve servlets can serve static files from a given directory)


I hope this explains my case.

Still not quite, sorry.

Jonathon Lamon

unread,
Apr 17, 2021, 3:15:36 PMApr 17
to google-web-tool...@googlegroups.com
I have just recently set this up.. with the current GWT plugin for Eclipse because I actually needed to run some JaxB servlets.  I ran into problems with JaxB servlets not loading when running in embedded Jetty, but setting up CodeServer runner with a launchDir pointing to the war folder and running deploying my GWT project to Tomcat.  When the Tomcat server started, it would automatically start the CodeServer.

I only saw these problems:

Restarting tomcat server without stopping CodeServer would cause multiple CodeServers to run.  IE CodeServer does not check if it is already running against an existing launchDir.

I ran into classpath and compilation issues where CodeServer would not generate serializable entities for some of my classes that work fine under DevMode.

CoseServer seemed to take an extra long time to compile vs DevMode.

My project is extremely large so there are many modules, some gwt some not, somewhere between 20-30 projects altogether and Multiple GWT modules.  Runs fabulously, for the most part under DevMode, but CodeServer just seems to have trouble.  I am surr that this is just do to various options set differently at runtime and perhaps some classpath loading differences, but an example that shows how to run CodeServer to reproduce the effect of running under DevMode would be imperative before removing DevMode.


 

Jonathon Lamon

DevOps Manager / Principal Engineer Special Projects
Perceptronics Solutions Inc.


From: google-web-tool...@googlegroups.com <google-web-tool...@googlegroups.com> on behalf of eliasb...@gmail.com <eliasb...@gmail.com>
Sent: Saturday, April 17, 2021 2:45:35 PM
To: GWT Contributors <google-web-tool...@googlegroups.com>
Subject: Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support
 

CAUTION -- EXTERNAL E-MAIL

You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4486df4d-553d-409f-b3a8-4b4887ff0b9fn%40googlegroups.com.

CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments unless you recognize the sender.


The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

Thomas Broyer

unread,
Apr 17, 2021, 3:32:13 PMApr 17
to Google Web Toolkit Contributors


Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon <jo...@percsolutions.com> a écrit :
I have just recently set this up.. with the current GWT plugin for Eclipse because I actually needed to run some JaxB servlets.  I ran into problems with JaxB servlets not loading when running in embedded Jetty, but setting up CodeServer runner with a launchDir pointing to the war folder and running deploying my GWT project to Tomcat.  When the Tomcat server started, it would automatically start the CodeServer.

I only saw these problems:

Restarting tomcat server without stopping CodeServer would cause multiple CodeServers to run.  IE CodeServer does not check if it is already running against an existing launchDir.

I ran into classpath and compilation issues where CodeServer would not generate serializable entities for some of my classes that work fine under DevMode.

CoseServer seemed to take an extra long time to compile vs DevMode.

Given that DevMode actually just runs CodeServer itself (literally: https://github.com/gwtproject/gwt/blob/8e09375adcc0a3ac976ba74286589d6d7007958d/dev/core/src/com/google/gwt/dev/shell/SuperDevListener.java#L99), I don't think this is possible.
Could be due to more pressure on your computer resources (memory and/or CPU) in that configuration maybe?



My project is extremely large so there are many modules, some gwt some not, somewhere between 20-30 projects altogether and Multiple GWT modules.  Runs fabulously, for the most part under DevMode, but CodeServer just seems to have trouble.  I am surr that this is just do to various options set differently at runtime and perhaps some classpath loading differences, but an example that shows how to run CodeServer to reproduce the effect of running under DevMode would be imperative before removing DevMode.

IIRC the CodeServer arguments are logged in DevMode window so you could copy-paste them. Use the same classpath, just change the main class from DevMode to CodeServer and change the arguments.
Or continue to use DevMode and just pass -noserver.

eliasb...@gmail.com

unread,
Apr 17, 2021, 4:07:16 PMApr 17
to GWT Contributors
OK, I guess not many people have used this technique.

So, I will try explaining this in a different way.

Indeed, DevMode runs a CodeServer itself.

We have a GWT Maven project and we run it using the "DevMode" runner of "Google Plugin for Eclipse", in a single step, instead of running CodeServer and servlet container separately etc.

This starts DevMode (with internal codeserver) and a Jetty server on a given TCP port.

When accessing the application from a browser, DevMode compiles the GWT client-code at runtime and delivers it to the browser (no separate codeserver, no separate servlet container etc.)

>> Same with CodeServer with -launcherDir, or DevMode with -noserver
This is equivalent to DevMode without "noserver".

>> What would be the workflow with DevMode serving only static files, and servlets deployed separately?
The workflow would be the same, it is just the GWT client-side code wouldn't know how to access the server-side code.

I hope this explains things better.

Thomas Broyer

unread,
Apr 18, 2021, 8:33:15 AMApr 18
to Google Web Toolkit Contributors
On Sat, Apr 17, 2021 at 10:07 PM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
OK, I guess not many people have used this technique.

This is what we're advocating for years: separate your client and server code, run the server code in one server, run the client code with "DevMode -noserver" or "CodeServer -launcherDir".
I started gwt-maven-archetypes with that technique 9 years ago this month, and have been advocating this since then: http://blog.ltgt.net/announcing-gwt-maven-archetypes-project/
This was even before SuperDevMode was a thing (and I was using this project layout at work for nearly 2 years already).
And as I linked earlier, GWT Eclipse Plugin supports this for years too (https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/Tomcat.html; the Youtube videos date back to Nov 2016)
 
So, I will try explaining this in a different way.

Indeed, DevMode runs a CodeServer itself.

We have a GWT Maven project and we run it using the "DevMode" runner of "Google Plugin for Eclipse", in a single step, instead of running CodeServer and servlet container separately etc.

Do you really mean "Google Plugin for Eclipse"?
Because it's been dead for quite a while (https://cloud.google.com/eclipse/docs/migrating-gpe / https://github.com/GoogleCloudPlatform/google-cloud-eclipse/wiki/Migrating-from-the-Google-Plugin-for-Eclipse), replaced by Cloud Tools for Eclipse (from Google) and GWT Eclipse Plugin (single-handedly maintained by Brandon Donnelson, from the original Google Plugin for Eclipse source code, but Brandon no longer does much GWT as Sencha, his employer, silently moved away from it a couple years ago)
Google Plugin for Eclipse does not support Eclipse 4.7 (Oxygen), which was released in the summer 2017.
 
This starts DevMode (with internal codeserver) and a Jetty server on a given TCP port.

When accessing the application from a browser, DevMode compiles the GWT client-code at runtime and delivers it to the browser (no separate codeserver, no separate servlet container etc.)

>> Same with CodeServer with -launcherDir, or DevMode with -noserver
This is equivalent to DevMode without "noserver".

>> What would be the workflow with DevMode serving only static files, and servlets deployed separately?
The workflow would be the same, it is just the GWT client-side code wouldn't know how to access the server-side code.

The same as what?
Sorry but I want to make sure we clearly understand each other.
If you're saying that the workflow would be the same as what you're describing above, then I don't understand: you're deploying servlets separately, so you at least need an additional step to do that.
If you're saying it's the same as what you described earlier (and quoted below), then I don't understand why you said “We could run the GWT server-side only code separately, not a problem at all.”

Here's what the workflow is/should be for many/most people:
  • if you're using an IDE with special GWT support (GWT Eclipse Plugin; IntelliJ IDEA Ultimate), then it's just one click; launches both a servlet where your webapp is deployed, and the CodeServer (or DevMode -noserver) for your client code. Similar things are available in some Gradle plugins. I don't know much more as I don't use any of those.
  • otherwise:
    1. launch a server where you webapp is deployed; it should be able to serve static resources from a given directory
    2. launch CodeServer (or DevMode -noserver) with -launcherDir (or -war) pointing to the directory where your static resources are served from
    3. there's no third step; open your webapp (possibly with the help of DevMode's -startupUrl) and upon loading the nocache.js (generated by GWT at launch of step 2, served from the server in step 1) it'll compile your client code on the fly. Everything works exactly the same as with DevMode and the embedded webapp server; with the difference that your server-side code is in another server so re-deploying it works differently (depends on that server then, and tooling around it)
This is actually (almost) the same as if you used a JS toolchain in "watch" mode. If you'd prefer something more like a "devserver" (à la webpack-dev-server) which would proxy requests to your backend, then I had started https://github.com/tbroyer/gwt-devserver which never gained traction; feel free to fork it, it's under the rather liberal Apache 2.0 license.

eliasb...@gmail.com

unread,
Apr 18, 2021, 9:16:47 AMApr 18
to GWT Contributors
Apologies for the confusion, I meant "GWT Eclipse Plugin" and its "DevMode" launcher.
This starts DevMode without "-noserver" plus a Jetty server at a given port and an internal codeserver which compiles the GWT client-side code at runtime and delivers the generated content to the browser all with a single step.

Practically our developers need only to run a DevMode launcher, no separate codeserver, no separate servlet container etc.
This is what I meant when I said it is very simple and shouldn't change.
It is indeed a single click.

Now, this doesn't work for GWT 2.9.0 or later, because of the classpath misalignment.
gwt-dev of GWT 2.9.0 makes use of ASM 7.1 while associated Jetty uses ASM 5.0.1 (see https://github.com/gwtproject/gwt/issues/9720)

However, ASM 5.0.1 seems to be required for Java7 support.
Therefore, if Java7 support is dropped then we could upgrade Jetty and keep the GWT classpath aligned with the classpath of the associated Jetty.

This would allow people to keep using the "GWT Eclipse Plugin" recipe with GWT 2.9.0+

That's the point I am trying to make.
I hope I am explaining this better this time.

Thomas Broyer

unread,
Apr 18, 2021, 11:41:02 AMApr 18
to Google Web Toolkit Contributors
On Sun, Apr 18, 2021 at 3:16 PM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
Apologies for the confusion, I meant "GWT Eclipse Plugin" and its "DevMode" launcher.
This starts DevMode without "-noserver" plus a Jetty server at a given port and an internal codeserver which compiles the GWT client-side code at runtime and delivers the generated content to the browser all with a single step.

Practically our developers need only to run a DevMode launcher, no separate codeserver, no separate servlet container etc.
This is what I meant when I said it is very simple and shouldn't change.
It is indeed a single click.

And there are other "single click" solutions with Eclipse, particularly with the GWT Eclipse Plugin.
 
Now, this doesn't work for GWT 2.9.0 or later, because of the classpath misalignment.
gwt-dev of GWT 2.9.0 makes use of ASM 7.1 while associated Jetty uses ASM 5.0.1 (see https://github.com/gwtproject/gwt/issues/9720)

That analysis is wrong, "dependency alignment" has nothing to do with any of the linked issues.
If you have a specific error, please file an issue (or update #9720) with that specific error and try to make a MCVE (https://stackoverflow.com/help/minimal-reproducible-example)
 
However, ASM 5.0.1 seems to be required for Java7 support.
Therefore, if Java7 support is dropped then we could upgrade Jetty and keep the GWT classpath aligned with the classpath of the associated Jetty.

This shows you're clearly not understanding how things work here.
 
This would allow people to keep using the "GWT Eclipse Plugin" recipe with GWT 2.9.0+

That's the point I am trying to make.
I hope I am explaining this better this time.

I'm getting tired of this discussion.
I try to be very specific, you keep hand-waving.
I ask specific questions, you don't answer them and keep saying the same thing over and over again.
You want a "single click" solution but refuse those "single click" alternatives that are suggested to you.
You don't show that you're knowing what you're talking about, or more precisely what your alternatives are; all you seem to want is that you absolutely wouldn't have to change the way you work. In other words, you expect others (GWT maintainers) to spend the time to build and maintain things because you don't want to spend the time investigating alternatives (that everyone else says you should be doing for many good reasons).

Now please answer that one question: what would your workflow be if you had to “run the GWT server-side only code separately”? as you said it's “not a problem at all”.
And please take the time to answer as specifically as possible, with as many details as you can. And don't hesitate to re-read all our exchanges in this thread.

 

eliasb...@gmail.com

unread,
Apr 18, 2021, 12:28:56 PMApr 18
to GWT Contributors
Perhaps I have indeed misunderstood parts of what you are trying to describe.

Hand waving or not, my main objection remains, DevMode embedded Jetty support must be preserved.

I have submitted a workaround to the chain at https://github.com/gwtproject/gwt/issues/9720

Thomas Broyer

unread,
Apr 18, 2021, 1:35:11 PMApr 18
to Google Web Toolkit Contributors
On Sun, Apr 18, 2021 at 6:29 PM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
Perhaps I have indeed misunderstood parts of what you are trying to describe.

Hand waving or not, my main objection remains, DevMode embedded Jetty support must be preserved.

Yet, you still haven't made the case for why it must be preserved.
And until then, all you've achieved is waste everyone's time.

I have submitted a workaround to the chain at https://github.com/gwtproject/gwt/issues/9720

Glad you found a workaround; but that's just delaying the inevitable. One day or another you'll probably have to change the way you run your project.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

eliasb...@gmail.com

unread,
Apr 18, 2021, 2:02:21 PMApr 18
to GWT Contributors
Thomas, I have explained this many times already.

Teams in the enterprise I work and probably many other teams worldwide are using DevMode with "GWT Eclipse Plugin" or other similar practices during development for a single click experience.

You seem to be suggesting that we should all abandon such practices and start running separate CodeServer instances and servlet container instances during development which will reduce productivity.

If you remove support for DevMode you will damage the projects that rely on it.

Regarding the workaround,
it can keep working unless you remove DevMode support.
Also, if I ever reach a dead end one day it would be because of a GWT structural change which would be unexpected.

If you are still believe I am wasting time then I am sorry but you are forcing me to say that you are being one-sided.

Thomas Broyer

unread,
Apr 18, 2021, 3:45:55 PMApr 18
to Google Web Toolkit Contributors
On Sun, Apr 18, 2021 at 8:02 PM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
Thomas, I have explained this many times already.

Teams in the enterprise I work and probably many other teams worldwide are using DevMode with "GWT Eclipse Plugin" or other similar practices during development for a single click experience.

You seem to be suggesting that we should all abandon such practices and start running separate CodeServer instances and servlet container instances during development which will reduce productivity.

For the third time, this is not a mutually exclusive situation! (with GWT Eclipse Plugin, or with IntelliJ IDEA Ultimate)

And even without using that specific GWT Eclipse Plugin support, that alternative of running things separately doesn't mean you cannot have them with a "single click experience" (using a launch group in Eclipse), and at worst it would be a 2-click experience (rather than the 5 steps or so that you described earlier).
In your case, based on that repo on GitHub, using Spring Boot and GWT, that would mean running your Spring Boot app using either "mvn spring-boot:run" or the Spring Tools plugin in Eclipse on one side; and the "DevMode -noserver" on the other side (with "mvn gwt:run" or the GWT Eclipse Plugin), and most importantly: be done with those classpath and classloader conflicts‼ It'd probably also simplify your project setup a lot (say goodbye to those 4 gwt-eclipse projects).
You apparently already have clearly separate projects for client and server code, so running them separately doesn't seem completely crazy.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

Paul Robinson

unread,
Apr 18, 2021, 6:30:26 PMApr 18
to google-web-tool...@googlegroups.com
On Sat, Apr 17, 2021 at 7:45 PM eliasb...@gmail.com <eliasb...@gmail.com> wrote:
During development,
with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse",
GWT client-side code compilation (including the nocache.js files) is done at runtime by DevMode.

Any other scenario demands that we,
separately compile the GWT client-side code,
separately run a servlet,
separately deploy the GWT code to the server (both client-side and server-side),
separately run GWT CodeServer,
then run a browser,
then genearate the CodeServer link etc.
The complexity difference is obvious.

It's not obvious because the 6 steps you listed are not 6 manually executed steps. Let's look at them:

(1) You can start servlets and CodeServer with one click.
(2) Compiling the GWT client code happens automatically on refreshing the browser page.  As Thomas said, it has been like this since GWT 2.7
(3) You don't need to deploy to the server - at least in Eclipse (and probably IntelliJ too) you can run a Jetty server inside Eclipse and have it use the Eclipse-compiled classpath.
(4) You do need to run a browser - but that's always required in every scenario.
(5) I don't know what you mean by "generate the CodeServer link" - you just point your browser at your servlet Jetty server and everything just works.
 
The only practical difference with the planned change is that you need to configure a servlet engine, and it then runs in two separate processes instead of one. But you can still initiate those two processes with a single click if that's important to you.

Paul

eliasb...@gmail.com

unread,
Apr 19, 2021, 3:24:10 AMApr 19
to GWT Contributors
> You can start servlets and CodeServer with one click.

Indeed, but don't ignore that this requires more setup work, which is not making the overall process simpler.
It is extra steps which we are unhappy to embrace.

> Compiling the GWT client code happens automatically on refreshing the browser page.  As Thomas said, it has been like this since GWT 2.7

We know that and our recipe relies very much on this, as I expect you have already figured out.

> You don't need to deploy to the server - at least in Eclipse (and probably IntelliJ too) you can run a Jetty server inside Eclipse and have it use the Eclipse-compiled classpath.

Again, this is an extra step which we are unhappy to embrace.

> You do need to run a browser - but that's always required in every scenario.

Indeed, but I am more referring to browser URL with CodeServer parameters which is usually created by drag-drop of some CodeServer bookmark.
Again, an extra step which we are unhappy having to embrace.

> I don't know what you mean by "generate the CodeServer link" - you just point your browser at your servlet Jetty server and everything just works.

I am referring to browser URL with CodeServer parameters which is usually created by drag-drop of some CodeServer bookmark.
Again, an extra step which we are unhappy having to embrace.

Finally:

We are unhappy having to setup more than one processes, even though all could be probably run with a single click.

Besides, with DevMode having been around since birth of GWT and probably one of GWT's best selling points, our recipe relies very much on it and removing it will have an impact to our development workflow.

Also, you don't seem to be suggesting any replacement for DevMode, which is another negative part of your approach in my view.

We prefer having to adjust the classpath as demonstrated in the example at https://github.com/gwtproject/gwt/issues/9720 until we reach a dead end, at which point we will have to switch to a CodeServer based recipe, even though I doubt this will happen.

Overall, I am getting the feeling that you are trying to push everyone to move away from DevMode to ease the GWT maintenance pains but this is not acceptable by us and probably by many other teams worldwide relying on DevMode based recipes.

Therefore, I don't see any reason not to keep DevMode as it is today and direct users wanting to take advantage of features not supported by Jetty to use CodeServer instead.

Please let's forget removal of DevMode as it won't keep everyone happy.

Gordan Krešić

unread,
Apr 19, 2021, 5:16:25 AMApr 19
to google-web-tool...@googlegroups.com
On 11. 04. 2021. 17:15, Jens wrote:
>
> Generally this would be a decision made by GWT steering group but I have no
> idea if this group still exists. So I am asking here for a decision how to
> move on.

Although I contributed a thing or two for GWT, I wouldn't call myself a
contributor (I'm not even sure I'm allowed to post on this list), but let me
drop my .2c.

First, let me say that I both understand and sympathize for the cases Elias
describes: when you have sufficiently large team and/or project, even small
changes in workflow could be extremely painful. No one likes that and I can
understand why not only Elias but probably many other may feel reluctant (to
be polite) about any non-backward-compatible changes.

Unfortunately, considering the shape GWT currently is, I really don't see
how investing into tech that has been deprecated for years could benefit
project in general.

GWT is currently in desperate shortage of maintainers, up to the point that
there are PRs not being merged because previous maintainers don't have time
to review them anymore. If we are to save GWT, not only we should drop ALL
deprecated stuff ASAP, but speed up deprecation of features that we are all
aware of that can't be maintained for much longer. I'll let others decide
which that are, but for example I just don't see any energy left in
community to provide full 2.x-level of compatibility while moving to
J2CL-based workflow. I hope I'm wrong, but these are MY .2c, so allow me :)

What I would like to see (and contribute to) is speed up adoption of J2CL
workflow (for example, docs are non-existent), even at the risk of
cannibalizing GWT 2.x compatibility work. When J2CL starts showing first
results in GWT community, only then we should restart work on providing
compatibility layer for GWT 2.x codebase and start modeling what should be
GWT 3. In other words: show everyone GWT still has a future (because not
everyone follows J2CL's repo commits like me :) ) and then existing users
may join in contributing support for existing code bases.

Otherwise, I'm afraid that GWT is on route to share COBOL's fate: not quite
dead, but definitely not alive either.

-gkresic.

eliasb...@gmail.com

unread,
Apr 19, 2021, 6:20:30 AMApr 19