My 2 cents:
We also have quite a few projects here based on GWT, still running DevMode
on Java 1.8 I am afraid.
Like everyone else sharing the same fate, we are struggling to upgrade to
Java 11 which seems to be the next sensible move.
Yet, the world is being indirectly and inevitably forced to
My 2 cents.
I am afraid some teams, like ours, are still using Java8 looking for the
next opportunity to move to Java11.
Perhaps, Java8 shouldn't be dropped yet.
On Saturday, 6 August 2022 at 16:06:28 UTC+1 ManfredTremmel wrote:
> In my company Java 8 was dropped long ago, at the moment the
Great , +1
On Thursday, 14 October 2021 at 22:03:53 UTC+1 nilo...@gmail.com wrote:
> I'm looking for reviewers and help for the above issues so I can finalize
> them and begin testing. There are a few dependency chains here - I have
> IE8/9/10 removal just about complete, but before that can
>> 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
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.
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
>>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
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
> 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
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
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
On Sunday, 18 April 2021
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
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
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
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?
On Saturday, 17 April 2021 at 18:45:39 UTC+1
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.
On Saturday, 17 April 2021 at 17:25:19 UTC+1 Paul Robinson wrote:
> Would it be plausible to
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
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
>> 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
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
I would happily invest in maintaining GWT to support my teams if I have to.
On Tuesday, 13 April 2021 at 20:11:05 UTC+1 t.br...@gmail.com wrote:
>
>
> Le mar. 13 avr. 2021 à 20:42, eliasb...@gmail.com a
> écrit :
>
>> Our developers are using "Google Plugin for Eclipse" from which they can
>>
Indeed.
It seems that bumping up Java is desirable or tolerable.
However, we cannot compromise with losing Jetty.
On Tuesday, 13 April 2021 at 20:01:43 UTC+1 ric...@gmail.com wrote:
> I should've been more explicit. The feature of having a self-contained app
> server for pure gwt frontend
Indeed.
It seems that bumbing up Java is desirable or tolerable.
However, we cannot compromise with losing Jetty.
On Tuesday, 13 April 2021 at 20:01:43 UTC+1 ric...@gmail.com wrote:
> I should've been more explicit. The feature of having a self-contained app
> server for pure gwt frontend
And yes we are packaging GWT apps as SpringBoot
On Tuesday, 13 April 2021 at 19:42:54 UTC+1 eliasbala...@gmail.com wrote:
> Our developers are using "Google Plugin for Eclipse" from which they can
> start DevMode for any of our GWT application with a single step.
>
&g
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
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
26 matches
Mail list logo
