Asking for decision on DevMode embedded Jetty support

919 views
Skip to first unread message

Jens

unread,
Apr 11, 2021, 11:15:34 AM4/11/21
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 PM4/11/21
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 AM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
to GWT Contributors
And yes we are packaging GWT apps as SpringBoot

Richi Plana

unread,
Apr 13, 2021, 3:01:43 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 PM4/13/21
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 AM4/14/21
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 AM4/14/21
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 AM4/14/21
to google-web-tool...@googlegroups.com

Paul Robinson

unread,
Apr 15, 2021, 2:56:43 AM4/15/21
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 AM4/15/21
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 AM4/15/21
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 AM4/15/21
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 PM4/15/21
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 AM4/16/21
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 AM4/16/21
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 AM4/16/21
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 AM4/16/21
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 PM4/16/21
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 AM4/17/21
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 AM4/17/21
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 AM4/17/21
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 PM4/17/21
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 PM4/17/21