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.