Asking for decision on DevMode embedded Jetty support

[Jens]

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]

For reference:

Jetty ASM issues:

https://github.com/gwtproject/gwt/issues/9606

https://github.com/gwtproject/gwt/issues/9693

https://github.com/gwtproject/gwt/issues/9720

Jakarta servlet support question:

https://github.com/gwtproject/gwt/issues/9727

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]

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]

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]

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]

Which features are you talking about? Which would you lose by switching to using a *real* Jetty server alongside GWT CodeServer?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c317be1c-55d9-f255-0b0f-e05da19240ee%40gmail.com.

[Frank Hossfeld]

@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]

- 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]

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]

And yes we are packaging GWT apps as SpringBoot

[Richi Plana]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEOAgJFjDiacN7w31ASa3pg8bL%2B0mEOc1Q7Sy1cdCtTd4w%40mail.gmail.com.

[eliasb...@gmail.com]

Indeed.

It seems that bumping up Java is desirable or tolerable.

However, we cannot compromise with losing Jetty.

[Thomas Broyer]

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.

Actually, not really: http://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/Tomcat.html

(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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAA5%3Digxoak0nwLOw%2B%3Dtyy0UXNpSaqp4_yL5DJsPM_4_jADEg4Q%40mail.gmail.com.

[eliasb...@gmail.com]

I would happily invest in maintaining GWT to support my teams if I have to.

[eliasb...@gmail.com]

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]

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:

* Common GWT module: https://github.com/react4j/react4j-heart-rate-monitor/blob/master/src/main/java/react4j/hrm/HeartRateMonitor.gwt.xml

* Development GWT module: https://github.com/react4j/react4j-heart-rate-monitor/blob/master/src/main/java/react4j/hrm/HeartRateMonitorDev.gwt.xml

* Production GWT module: https://github.com/react4j/react4j-heart-rate-monitor/blob/master/src/main/java/react4j/hrm/HeartRateMonitorProd.gwt.xml

* Common public assets: https://github.com/react4j/react4j-heart-rate-monitor/tree/master/src/main/java/react4j/hrm/public/common

* Development GWT Asset (just a launch page): https://github.com/react4j/react4j-heart-rate-monitor/tree/master/src/main/java/react4j/hrm/public/dev

* Production GWT Asset (just a launch page): https://github.com/react4j/react4j-heart-rate-monitor/tree/master/src/main/java/react4j/hrm/public/prod

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]

>> 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]

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]

Mocked services on the server side. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEPYzJ49Ch11AFnREySWf%2BQKDEtCrw4jLy4iLzxnQ6fz-Q%40mail.gmail.com.

[Paul Robinson]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWN%2BYgug5qMirEg-6fDC1Lyj6xvsh7VHBJ4xdicq1UwPOAA%40mail.gmail.com.

[Michael Conrad]

How would this impact Super Dev Mode in Gradle?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKbOjEyDaFzcK1hiKd_L4Oux1CYng1LHDsEimaXjX2jH91zdBw%40mail.gmail.com.

[Thomas Broyer]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEOHFCL4YfWG2Gb--H3d9Amxr8BhPrwCF35QYu9RwpJKWQ%40mail.gmail.com.

[Vassilis Virvilis]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CACiKNc7nSFd9PUzHQwtgai7EZriU3EOimzBtRgRro1TQ4jfObg%40mail.gmail.com.

--

Vassilis Virvilis

[Paul Robinson]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNJQdCRQ5NfRA--B7SLmxBZikc1tjfiabfX8%2BKnDWTgYOQ%40mail.gmail.com.

[Thomas Broyer]

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)

See http://www.gwtproject.org/articles/superdevmode.html

 

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEMoy2bfbATDMstqUsmS88Zg0N8w1bYatdgwZrOYtJtbPQ%40mail.gmail.com.

--

Vassilis Virvilis

[eliasb...@gmail.com]

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]

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)

See http://www.gwtproject.org/articles/superdevmode.html

 

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/16974302-ff52-4fc0-bcf7-4c25356e708en%40googlegroups.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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9cce0909-56fc-4804-a032-103184c05af1n%40googlegroups.com.

[eliasb...@gmail.com]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/94c5c53d-b72a-4887-a617-4d1064c7c8fan%40googlegroups.com.

[eliasb...@gmail.com]

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]

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.

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.

[Jonathon Lamon]

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.

Cell 269-205-4649

www.percsolutions.com

---

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/BN3P110MB0354A199D56BBA0158B8D7E2DC4B9%40BN3P110MB0354.NAMP110.PROD.OUTLOOK.COM.

[eliasb...@gmail.com]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ab443c9-cfea-4d63-8cfe-90311cab0c64n%40googlegroups.com.

--

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

[eliasb...@gmail.com]

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]

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.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8936a38c-7bce-4351-89e5-aab0cd9ab662n%40googlegroups.com.

--

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

[eliasb...@gmail.com]

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]

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]

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]

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]

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]

> 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ć]

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]

Thanks Gordan Krešić,

Here is my "two cents".

I am in favor of J2CL adoption and I don't want to see GWT sharing COBOL's fate either.

Yet, I hadn't realized that GWT has been under such a severe shortage of maintainers.

But, I am wondering, what should we be considering as deprecated?

Java7 support?

I would say yes.

DevMode with Embedded Jetty?

I have to say no.

Other?

Probably yes.

[Bernhard Schulz]

Hi all!

I am catching up on some statements in the last mails.

> 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.

I also understand, that no one likes such changes, but nobody is forcing anyone to upgrade. He and his team can use his setup for the next 20 years, if he wants to.

> I really don't see how investing into tech that has been deprecated for years could benefit project in general.

100% agree!

> If we are to save GWT, not only we should drop ALL deprecated stuff ASAP

100% agree!


I have the feeling, that a small minority is blocking all the innovations (by not allowing do drop deprecated stuff) and make life hard for GWT maintainers and thus blocking us all from more/faster innovations.
I would suggest just not listening to them.

I am very thankful for all the work which was but into GWT.
I can use it free-of-charge.
Unfortunately, I am not good enough as a coder to become a maintainer, but I did and will donate to various GWT / GWT related projects and I can say „thank you“ and support their journey to have a maintainable GWT stack without old stuff.

If there are big enterprises with big GWT projects, they sure have the money to either upgrade the software and train their stuff to a recent GWT setup or to hire someone who backports stuff for them if really necessary.

Thanks

[eliasb...@gmail.com]

>>I also understand, that no one likes such changes, but nobody is forcing anyone to upgrade. He and his team can use his setup for the next 20 years, if he wants to.

We always try to upgrade to latest stable version of any technology we use.

GWT 2.9.0 then J2CL etc.

If something is broken or gets discontinued we get locked to an older version.

So, indeed nobody is forcing anyone to upgrade but not upgrading is not a good option either.

e.g. if DevMode with embedded Jetty gets removed we are stuck with current GWT version, not good.

>>I am very thankful for all the work which was put into GWT.

Great work indeed.

> If we are to save GWT, not only we should drop ALL deprecated stuff ASAP

We could remove Java 7 support perhaps.

[Lofi Dewanto]

I'm not contributor of GWT but like the framework very much and already use it since 2008 or so...

I see that GWT / J2CL still has the potential to make Java devs productive. In my last experience a lot of Java devs in my division want to use Vue.js and now I see that we need to educate all of them with JavaScript, Vue.js and they are not productive yet. So you see a lot of JavaScript / Vue.js spaghetti code. Not nice.

But now back to this discussion. I actually like the "devmode" like what @elias uses.

Why?

• For demo purpose it is great, you just run one process (jetty + codeserver), that's it, you can directly show the result. You don't need to run 2 processes.
• I always separate the client / server project but I don't want to build my server project with the help of GWT Maven project. Why?
  • There are a lot of server projects out there: Spring Boot, Micronaut, Quarkus, PHP, Dot-NET, Apache only, NGINX only, etc. So I want to generate the server code using the tools offered by the servlet framework. E.g. Spring Boot: on the server part I generate the Maven project of Spring Boot using Spring Boot 
  • So actually for deployment I just copy the result of the JavaScript (client) to the directory of the server framework and run the server.

What I don't understand so far, why does Jetty disturbs the whole classpath concept? I only use devmode on the client and on the client I don't have server libs... Is it not possible just to use the needed Jetty server for GWT (I'm not sure where else do we need the Jetty libs in GWT code)? Because actually I don't care what version of Jetty should be used in GWT... the main thing: I could run web server + code server in the same process with one execution.

Another possibility: run the Jetty for devmode in the GWT Maven plugin? So you only have the Jetty on the classpath of the Maven plugin?

To show you my use case, here is an example: https://github.com/gwtboot/domino-rest-enum-date

Just my 2 cents,

Lofi

[Thomas Broyer]

On Tue, May 4, 2021 at 3:15 AM 'Lofi Dewanto' via GWT Contributors <google-web-tool...@googlegroups.com> wrote:

What I don't understand so far, why does Jetty disturbs the whole classpath concept?

There are many issues, depending on who you ask and how they use GWT.

The issue that started this discussion about upgrading Jetty is that Jetty scans the WEB-INF/lib JARs, and the version we use in GWT will fail on any module-info.class.

Other issues with how Jetty is used in DevMode is that we give it a special WebAppClassLoader that doesn't work like a standard web-app classloader in that it will resolves classes from both the WEB-INF/classes and WEB-INF/lib, and the DevMode classpath. This was done so that you don't need to "assemble" an "exploded WAR" (compiling your server code to WEB-INF/classes, putting your server dependencies to WEB-INF/lib). This has caused many issues over the years (Spring failing because it saw its configuration twice: from the WEB-INF/classes and from the classpath; some libraries from the classpath leaking to the web-app classloader; etc.), and makes upgrading Jetty is unnecessarily hard and error-prone (last time we did, I spent hours fixing it).

And I'm not even talking about people asking for JSP support, or jetty-web.xml support (e.g. to configure form authentication or JNDI resources), or web-fragments, annotation scanning (that's now causing the issues with modules)

Everything would be much much simpler if we removed all those features to only support the bare minimum (static files), or possibly re-introduce the <servlet> support in gwt.xml (and totally removing web.xml support), or as a last resort making it extra-clear that this only supports "demo-size" projects (after we remove the custom classloader, and possibly JSP and jetty-web.xml) and that if it breaks or you need more features then you just don't use it.

The last issue is actually a non-issue (and that was actually Elias' problem, or at least part of it): people misconfiguring their classpath and including other Jetty or servlet libraries in the classpath. We can't do anything here, that's a classpath management issue and it would be the same with many other dependencies (e.g. upgrade HTMLUnit, you'll see your tests fail).

 

I only use devmode on the client and on the client I don't have server libs... Is it not possible just to use the needed Jetty server for GWT (I'm not sure where else do we need the Jetty libs in GWT code)?

Jetty is used for the CodeServer itself (that could probably be migrated to using com.sun.net.httpserver), and for the JUnitShell (that one needs to support basic servlets, so no com.sun.net.httpserver here).

And the Jetty version needs to be aligned with what HTMLUnit uses, as it requires some Jetty client libraries (mostly for websocket support IIRC) that transitively require some Jetty "common" libraries (jetty-util, jetty-io).

 

Because actually I don't care what version of Jetty should be used in GWT... the main thing: I could run web server + code server in the same process with one execution.

I don't really get what point you're trying to make. If you don't have server code in your DevMode, then you're not impacted by the change being discussed here.

Another possibility: run the Jetty for devmode in the GWT Maven plugin? So you only have the Jetty on the classpath of the Maven plugin?

To show you my use case, here is an example: https://github.com/gwtboot/domino-rest-enum-date

Where you're starting your Spring Boot server separately from DevMode (so you have 2 processes, not just one, contrary to what you're saying above), whose embedded server only serves a (development-only) static HTML page.

That's probably not how I would work with Spring Boot, but indeed that works too.

--

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

[eliasb...@gmail.com]

My 2 cents,

I understand very well where "Lofi" is coming from.

He tries to simplify the GWT server-side by moving all the potentially conflicting classpath dependencies to a separate application.

This recipe indeed involves an extra step but it doesn't change at all the situation with "DevMode+Jetty" and the associated classpath misalignment, particularly with GWT 2.9+ while the "DevMode+Jetty+CodeServer" combination still runs in a single step.

Therefore, I still vote in favor of keeping DevMode, removing support for Java7, upgrading Jety to more recent version and use of same transitive dependencies between GWT and Jetty (e.g. ASM).

FYI, if it helps anyone, I have found a workaround to the classpath misalignment issue (see https://github.com/gwtproject/gwt/issues/9693#issuecomment-822016533) which works both for GWT2.9+ and previous versions.

[Dr. Lofi Dewanto]

@Thomas: thanks a lot for the insight...

Yes, you are correct I only use the embedded Jetty Server to serve (development-only) static HTML page. And I won't ever need more than this...

So then I think, I don't really understand what @Elias means sofar... I thought, he had the same installment like my structure? Damn already work with GWT since 2008 but still cannot see what the difference using devmode in my case and in @Elias case... :-) :-)

I had once this structure: https://github.com/interseroh/demo-gwt-springboot but today I won't do this anymore... The classpath is a very big problem here...

@Elias: Is there any problem to move to the structure like I have here in this example? https://github.com/gwtboot/domino-rest-enum-date

I once write this tool MoveToMaven: https://github.com/crowdcode-de/MoveToMaven to move Ant projects to Maven projects. Actually it is not that complex to write such a tool to move your "old" GWT Maven structure to the new GWT Maven structure automatically. It's good to have such a transformer if you have a lot of Maven projects...

Thanks,

Lofi

[eliasb...@gmail.com]

In my experience,

as long as the GWT server-side is lightweight enough to run under Jetty there shouldn't be any major problems with any structure.

Also, with Maven (or other build engines) you can manipulate the classpath and resolve SuperDevMode+Jetty classpath conflicts during development.

In general, GWT applications are expected to be quite lightweight, not monolithic, comparable to demo-sized apps in terms of capability to run under SuperDevMode's embedded Jetty.

Any heavyweight logic should be moved to separate applications, a "microservices" approach.

Therefore, I see no reason to stop using SuperDevMode with Embedded Jetty.

Your structure is in fact even more simplified and lightweight, even though it requires additional APIs work.

I would be happy to give it a try in one of our future projects.

I haven't used https://github.com/interseroh/demo-gwt-springboot but I have created my own equivalent at https://github.com/eliasbalasis/eclipse-gwt-recipe

I hope this helps

Elias

[Thomas Broyer]

On Tue, May 4, 2021 at 10:20 AM eliasb...@gmail.com <eliasb...@gmail.com> wrote:

My 2 cents,

I understand very well where "Lofi" is coming from.

He tries to simplify the GWT server-side by moving all the potentially conflicting classpath dependencies to a separate application.

Er, no.

He cleanly separates the server classpath from GWT's classpath, because there's absolutely zero reason you would put your server-side dependencies in the classpath for building your client-side code (you'll never use a Spring class from your GWT client code, so why put Spring in the classpath?). All this does is make GWT slower (because it scans the entire classpath, so the bigger it is, the slower the scanning) and create conflicts (exactly what you've experienced)

This is what everyone says you should do and you refuse to because… reasons.

(note that it doesn't even mean that you cannot serve your webapp from DevMode, as the webapp should get its classes from WEB-INF/lib)

 

This recipe indeed involves an extra step but it doesn't change at all the situation with "DevMode+Jetty" and the associated classpath misalignment, particularly with GWT 2.9+ while the "DevMode+Jetty+CodeServer" combination still runs in a single step.

Therefore, I still vote in favor of keeping DevMode, removing support for Java7, upgrading Jety to more recent version and use of same transitive dependencies between GWT and Jetty (e.g. ASM).

Can you stop talking about "classpath misalignment"? I already explained there's no issue with what GWT currently does wrt ASM.

 

FYI, if it helps anyone, I have found a workaround to the classpath misalignment issue (see https://github.com/gwtproject/gwt/issues/9693#issuecomment-822016533) which works both for GWT2.9+ and previous versions.

Here you're fixing a Maven dependency "mediation" issue where Maven picks a version of ASM that's not compatible with GWT. This is a classpath management issue that's unrelated to GWT (had you used Gradle for instance, it would have been different, because it would have picked the highest ASM version), and of course this is because you put your server-side dependencies in GWT's classpath (with a very convoluted setup; https://xkcd.com/1172/).

--

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

[eliasb...@gmail.com]

>> This is what everyone says you should do and you refuse to because… reasons.

I have never disagreed to that, see https://github.com/gwtproject/gwt/issues/9693#issuecomment-816517718

I even have considered adopting such an approach, like Lofi's, in future projects.

What I am against is being pushed to move away from use of "Embedded Jetty".

>> Can you stop talking about "classpath misalignment"? I already explained there's no issue with what GWT currently does wrt ASM.

Fine, I am happy to call this whatever you please.

I have produced a workaround which will keep working as long as EmbeddedJetty doesn't get retired.

However, a part of me would still prefer seeing GWT being built with a more recent version of Jetty and ideally same ASM etc. to enforce use of same API baselines. Your call.

>> This is a classpath management issue that's unrelated to GWT

Fine, I am happy to call this whatever you please.

The workaround will keep satisfying my needs as long as EmbeddedJetty doesn't get retired.

However, a part of me would still prefer seeing GWT being built with a more recent version of Jetty and ideally same ASM etc. to enforce use of same API baselines. Your call.

Long story short, don't remove EmbeddedJetty support from DevMode and please stop pushing people to move away from "Embedded Jetty" if they don't want to for their own reasons.