Re: Project moved now compile errors

[eliasbala...@gmail.com]

I think you have stumbled upon a known issue.

Class "com.smartgwt.client.data.Record" conflicts with "Record" in more 
recent versions of Java

see 
https://forums.smartclient.com/forum/smart-gwt-technical-q-a/270433-smartgwt-6-1-is-incompatible-with-java17

I hope this has been fixed in later versions of SmartGWT.
We will find out as soon as we try to switch to Java17.

I hope this helps you.

On Wednesday, 13 September 2023 at 15:03:26 UTC+1 Frank Hossfeld wrote:

Might be a problem with the jdk version ... 
IIRC, record was added in Java 14 (not sure). It looks like a jdk version > 
13 is used to build. 
Not sure if SmartGWT is supporting newer jdk version than version 8.

Next problem might be Eclipse itself. Newer Eclipse version need something 
greater than Java 8.

Hope that helps. 
 

blackh...@gmail.com schrieb am Mittwoch, 13. September 2023 um 08:58:57 
UTC+2:

Hi,

We have a so called build server, where we build all our projects. This is 
just a server where eclipse is running and where we build our projects with 
ant.

As the server was/is getting old (windows 2008R2), we have set up a new one 
(windows 2022). We installed eclipse with the same configuration as on the 
old server. Same Java versions installed too.
We checked out the projects and now 1 of the projects does not compile the 
web stuff.
The other projects do build normal.

I have attached the compile log. Can anyone explain what is happening and 
what i am missing to fix this?

Regards,

Jasper

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c81bd859-305a-4afc-9af6-56cbad17127en%40googlegroups.com.

Re: GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

Many thanks, this is great.

I was planning to wait for the official release, but since you are that 
much satisfied I will give it a try.

On Friday, 6 January 2023 at 12:17:28 UTC abhiy...@gmail.com wrote:

> Hi All
>
> You can use the GWT eclipse plugin which is made compatible with latest 
> version of eclipse 4.26(2022-12) by someone from the GWT community. I am 
> providing the link below.
>
> *http://keeitsi.com/software/eclipse-plugins/ 
> *
> I am using this plugin and it works perfectly fine on the latest version 
> of eclipse.
>
> On Friday, January 6, 2023 at 5:30:49 PM UTC+5:30 eliasb...@gmail.com 
> wrote:
>
>> I believe I was using the GWT Eclipse Plugin content from Eclipse 
>> Marketplace which does not exist anymore.
>>
>> The alterrnatives 
>> http://storage.googleapis.com/gwt-eclipse-plugin/v3/release and 
>> http://storage.googleapis.com/gwt-eclipse-plugin/v3/snapshot work only 
>> up to Eclipse 2021-09
>>
>> On Friday, 24 June 2022 at 16:13:44 UTC+1 mtil...@gmail.com wrote:
>>
>>> Any clue about how you got it to work? It still don't work for me on 
>>> 2022-03. It installs but does not really add anything. On 2022-06 it 
>>> refuses to install.
>>>
>>>
>>> On Tuesday, 24 May 2022 at 09:08:45 UTC+2 eliasb...@gmail.com wrote:
>>>
 This seems to be working finally.

 To my surprise, I repeated the experiment and [GWT Eclipse Plugin] is 
 fully accessible and operational.

 I am now confused.

 On Monday, 23 May 2022 at 23:37:41 UTC+1 hprc wrote:

>
> I also use the GWT Eclipse Plugin.
> Currently, the Eclipse side is up to 202103, and seems to be up to 
> JDK1.8.
>
> The official documentation still only describes this plugin, so I'd 
> like you to add a method with the Moven plugin as soon as possible.
> (Preferably with illustrations)
> 2022年5月24日火曜日 6:57:01 UTC+9 eliasb...@gmail.com:
>
>> [GWT Eclipse Plugin] has served us very well.
>>
>> It is quite unfortunate but I fear the time for putting it to rest is 
>> approaching, if it hasn't already come.
>>
>> I just don't want to give up yet :-)
>>
>> On Monday, 23 May 2022 at 03:46:42 UTC+1 hprc wrote:
>>
>>>
>>> It's certainly interesting.
>>> However, do you recognize that the development of [GWT Eclipse 
>>> Plugin] will not be continued anymore?
>>> 2022年5月22日日曜日 18:16:34 UTC+9 eliasb...@gmail.com:
>>>
 Interesting...

 But you are using STS distribution not the standard, perhaps 
 something is different in the STS distribution compared to the primary 
 Eclipse Foundation's distribution.

 On Saturday, 14 May 2022 at 19:09:32 UTC+1 foal wrote:

> I am on Eclipse 4.22 (STS 4.13.1) and plugin still works (
> https://github.com/gwt-plugins/gwt-eclipse-plugin) 
>
> On Wednesday, May 4, 2022 at 12:56:47 AM UTC+2 Craig Mitchell 
> wrote:
>
>> I'm on Eclipse 2021-09 (4.21.0) and it works fine.
>>
>> However, after this version, the Google plugin stops working  
>> https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3659
>>   
>> so I haven't tried later versions.
>>
>> On Monday, 2 May 2022 at 11:17:23 pm UTC+10 eliasb...@gmail.com 
>> wrote:
>>
>>> Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still 
>>> working.
>>>
>>> Under Eclipse 2022-03, the preferences page, the GWT Development 
>>> view and the run configurations are not accessible.
>>>
>>> This is crucial for certain teams relying on GWT Eclipse Plugin 
>>> for running applications from within the Eclipse IDE and locks 
>>> users to 
>>> Eclipse 2021-03 permanently, unless this can be fixed.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/288451ca-2ad2-4090-be99-21265bdd8facn%40googlegroups.com.

Re: GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

I believe I was using the GWT Eclipse Plugin content from Eclipse 
Marketplace which does not exist anymore.

The 
alterrnatives http://storage.googleapis.com/gwt-eclipse-plugin/v3/release 
and http://storage.googleapis.com/gwt-eclipse-plugin/v3/snapshot work only 
up to Eclipse 2021-09

On Friday, 24 June 2022 at 16:13:44 UTC+1 mtils...@gmail.com wrote:

> Any clue about how you got it to work? It still don't work for me on 
> 2022-03. It installs but does not really add anything. On 2022-06 it 
> refuses to install.
>
>
> On Tuesday, 24 May 2022 at 09:08:45 UTC+2 eliasb...@gmail.com wrote:
>
>> This seems to be working finally.
>>
>> To my surprise, I repeated the experiment and [GWT Eclipse Plugin] is 
>> fully accessible and operational.
>>
>> I am now confused.
>>
>> On Monday, 23 May 2022 at 23:37:41 UTC+1 hprc wrote:
>>
>>>
>>> I also use the GWT Eclipse Plugin.
>>> Currently, the Eclipse side is up to 202103, and seems to be up to 
>>> JDK1.8.
>>>
>>> The official documentation still only describes this plugin, so I'd like 
>>> you to add a method with the Moven plugin as soon as possible.
>>> (Preferably with illustrations)
>>> 2022年5月24日火曜日 6:57:01 UTC+9 eliasb...@gmail.com:
>>>
 [GWT Eclipse Plugin] has served us very well.

 It is quite unfortunate but I fear the time for putting it to rest is 
 approaching, if it hasn't already come.

 I just don't want to give up yet :-)

 On Monday, 23 May 2022 at 03:46:42 UTC+1 hprc wrote:

>
> It's certainly interesting.
> However, do you recognize that the development of [GWT Eclipse Plugin] 
> will not be continued anymore?
> 2022年5月22日日曜日 18:16:34 UTC+9 eliasb...@gmail.com:
>
>> Interesting...
>>
>> But you are using STS distribution not the standard, perhaps 
>> something is different in the STS distribution compared to the primary 
>> Eclipse Foundation's distribution.
>>
>> On Saturday, 14 May 2022 at 19:09:32 UTC+1 foal wrote:
>>
>>> I am on Eclipse 4.22 (STS 4.13.1) and plugin still works (
>>> https://github.com/gwt-plugins/gwt-eclipse-plugin) 
>>>
>>> On Wednesday, May 4, 2022 at 12:56:47 AM UTC+2 Craig Mitchell wrote:
>>>
 I'm on Eclipse 2021-09 (4.21.0) and it works fine.

 However, after this version, the Google plugin stops working  
 https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3659
   
 so I haven't tried later versions.

 On Monday, 2 May 2022 at 11:17:23 pm UTC+10 eliasb...@gmail.com 
 wrote:

> Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still 
> working.
>
> Under Eclipse 2022-03, the preferences page, the GWT Development 
> view and the run configurations are not accessible.
>
> This is crucial for certain teams relying on GWT Eclipse Plugin 
> for running applications from within the Eclipse IDE and locks users 
> to 
> Eclipse 2021-03 permanently, unless this can be fixed.
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/9a569dd7-c357-4914-9ee2-d9c7723381a9n%40googlegroups.com.

[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations

[eliasbala...@gmail.com]

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 embrace the 
transformation challenge, as relevant tools and integrations have already 
switched to Java 11 (e.g. Jenkins).

In our experience, when using DevMode, it is best to run simpler variants 
of the actual UI apps, or keep them as simple as possible so that they can 
still run on Jetty even with an altered classpath.

On Monday, 2 January 2023 at 13:10:59 UTC hthdjeu...@googlemail.com wrote:

> We have a project here that uses GWT for all its web UI and is still 
> running Java 1.8. The SAP JVM 8 will be supported at least until 2030. 
> According to 
> https://newrelic.com/resources/report/2022-state-of-java-ecosystem in 
> April 2022 still close to half of the projects (46%) were using Java 1.8. 
> We have made some efforts to move to 11 and 17 and succeeded to the degree 
> that we have the build pipelines running for those two new LTS versions 
> using their respective JDKs to compile, have our Docker images ready and 
> can run the solution with both these new Java LTS releases. But this took a 
> few months, and I find it very likely that from the 46% of the projects not 
> all have the resources to invest into the migration. If only half of them 
> do, we're still at those ~25% that Colin already sampled from the responses 
> on this thread who will continue to use 1.8 for some time to come.
>
> Still, we're not yet decided on making the move. Even when using the 
> sapmachine.io flavors of the new JDKs we will lose some beloved features 
> we get from SAP JVM 8, among them a really neat profiler that integrates 
> nicely with Eclipse, as well as reversible on-the-fly debugging. The only 
> immediate incentive for a migration to 17 could be the performance 
> improvements we measure (depending on the type of workload an average 
> improvement by 10-20%), whereas language features or the new GCs (which 
> frankly were a bit disappointing for our parallelizing workloads) are not 
> in such high demand in our case.
>
> Ironically, since we live off a fork of the GWT project to already 
> incorporate two PRs we've made into our production, Java 1.8 is still 
> required to run the GWT build...
>
> The compatibility issues raised here are of course all very valid. Some 
> things seem reasonably easy to deal with (see, e.g., 
> https://github.com/gwtproject/gwt/pull/9791). Other cases, some of which 
> discussed here, too, such as potentially giving up the classic DevMode in a 
> future release, and removing support for old IE versions in the current 
> 2.10 release, may break existing projects for sure. The same applies for 
> potential changes that don't deal "only" with bumping versions of 
> dependencies but that try to improve aspects of GWT at the expense of what 
> I would call minor compatibility glitches (see the discussion here: 
> https://github.com/gwtproject/gwt/pull/9779).
>
> With some of these things I find it a problem that GWT doesn't seem to 
> have a clearly defined "set of contracts" based on which "backward 
> compatibility" could be defined. There are, e.g., things that for technical 
> reasons have been made "protected" in non-final classes or public in other 
> classes that probably shouldn't count as part of the "GWT contract." Yet, 
> with enough projects out there in the wild there may be a few that exploit 
> exactly those elements and hence would break in case of changes in those 
> areas. Disallowing any change in any of these areas, however, may box GWT 
> in this compatibility trap forever. And having to postponse such changes to 
> releases that will break massively in other areas and hence may cause 
> disruption and lack of adoption for a fair share of GWT-based projects 
> doesn't seem ideal to me, either.
>
> Maybe we should take away from these challenges that it would be a good 
> thing going forward to be more explicit abut which parts of GWT are 
> contract and which ones are not; and those latter ones we then should be 
> able to change incompatibly without worrying about adopters.
> On Thursday, August 4, 2022 at 5:05:45 AM UTC+2 nilo...@gmail.com wrote:
>
>>
>>
>> If there’s one thing that GWT has tried to be consistent about, it is 
>> retaining support for technologies past their “best by” dates. This is a 
>> sore point from time to time, as it makes the tooling feel dated even right 
>> after a release, but it has some specific advantages with regards to 
>> enabling projects that are otherwise in maintenance mode to still be able 
>> to upgrade to a newer version. Similarly, GWT has traditionally only 
>> supported the current release, with no fixes backported, due to the extra 
>> work that would need to be done in testing, backporting, etc.
>>
>>
>> To 

Re: java.lang.ClassNotFoundException: javax.sql.DataSource when using GWT 2.9.0 + Java 11 combination

[eliasbala...@gmail.com]

I take back what I said.

It seems there are classpath resolution issues when using a custom 
"JettyLauncher" while running under "GWT Eclipse Plugin", probably due to 
different classloaders assignment.

I am afraid the time has finally come to abandon use of DevMode and the 
"GWt Eclipse Plugin", until this is fixed in later versions of GWT.

I hope a future version of GWT will make use of a Jetty version supporting 
a more elegant way to override the "allowedFromSystemClassLoader" variable.

On Monday, 19 December 2022 at 15:46:31 UTC eliasbala...@gmail.com wrote:

> Overriding JettyLauncher with  "javax.sql." on the 
> "allowedFromSystemClassLoader" variable has worked for me on a variety of 
> projects, using SuperDevMode + GWT 2.9.0 + JDK 11
>
> I hope a future version of GWT will make use of a Jetty version supporting 
> a more elegant way to override the "allowedFromSystemClassLoader" variable.
>
> On Friday, 1 July 2022 at 20:32:18 UTC+1 nam...@gmail.com wrote:
>
>> Hello all
>>
>> I use legacy dev mode with a old FF17 with succes on GWT 2.10 / jdk 11. I 
>> had to overide JettyLauncher class to add "javax.sql." on the 
>> "allowedFromSystemClassLoader" variable
>> Until now, I have no issue with this mode except this.
>>
>> Le jeu. 30 juin 2022 à 09:30, Thomas Broyer  a écrit :
>>
>>> Didn't legacy devmode also only work with JDK 8?
>>>
>>> On Wednesday, June 29, 2022 at 10:46:30 PM UTC+2 Jens wrote:
>>>
>>>> Without being able to see the project setup this is tough to answer.
>>>>
>>>> However regardless of the exception you are seeing: Classic/Legacy 
>>>> DevMode will not work with GWT 2.9.0 correctly, because GWT 2.9.0 already 
>>>> uses JsInterop internally in its Java SDK emulation (e.g. java.util.Date 
>>>> uses it). JsInterop is not supported by classic/legacy DevMode. With GWT 
>>>> 2.9.0 you have to use SuperDevMode to have a functional Java SDK emulation 
>>>> during development.
>>>>
>>>> -- J.
>>>>
>>>> abhiy...@gmail.com schrieb am Mittwoch, 29. Juni 2022 um 21:58:40 
>>>> UTC+2:
>>>>
>>>>> Hi Team,
>>>>>
>>>>> I am trying to start classic DEV mode in eclipse through GWT eclipse 
>>>>> plugin .
>>>>> I am using GWT 2.9.0 + Java 11 combination.
>>>>> I am getting below error. Can you help me in resolving the below error:
>>>>>
>>>>> [b]Caused by: java.lang.ClassNotFoundException: javax.sql.DataSource
>>>>> at 
>>>>> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload$WebAppClassLoaderExtension.findClass(JettyLauncher.java:478)
>>>>>  
>>>>> ~[gwt-dev-2.9.0.jar:?]
>>>>> at 
>>>>> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:441)
>>>>>  
>>>>>
>>>> -- 
>>>
>> You received this message because you are subscribed to the Google Groups 
>>> "GWT Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-web-tool...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit/6d3569b5-b7f0-4c2e-918c-c342b6803441n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/google-web-toolkit/6d3569b5-b7f0-4c2e-918c-c342b6803441n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/8f0d65cc-b082-4803-8072-459644d06126n%40googlegroups.com.

Re: java.lang.ClassNotFoundException: javax.sql.DataSource when using GWT 2.9.0 + Java 11 combination

[eliasbala...@gmail.com]

Overriding JettyLauncher with  "javax.sql." on the 
"allowedFromSystemClassLoader" variable has worked for me on a variety of 
projects, using SuperDevMode + GWT 2.9.0 + JDK 11

I hope a future version of GWT will make use of a Jetty version supporting 
a more elegant way to override the "allowedFromSystemClassLoader" variable.

On Friday, 1 July 2022 at 20:32:18 UTC+1 nam...@gmail.com wrote:

> Hello all
>
> I use legacy dev mode with a old FF17 with succes on GWT 2.10 / jdk 11. I 
> had to overide JettyLauncher class to add "javax.sql." on the 
> "allowedFromSystemClassLoader" variable
> Until now, I have no issue with this mode except this.
>
> Le jeu. 30 juin 2022 à 09:30, Thomas Broyer  a écrit :
>
>> Didn't legacy devmode also only work with JDK 8?
>>
>> On Wednesday, June 29, 2022 at 10:46:30 PM UTC+2 Jens wrote:
>>
>>> Without being able to see the project setup this is tough to answer.
>>>
>>> However regardless of the exception you are seeing: Classic/Legacy 
>>> DevMode will not work with GWT 2.9.0 correctly, because GWT 2.9.0 already 
>>> uses JsInterop internally in its Java SDK emulation (e.g. java.util.Date 
>>> uses it). JsInterop is not supported by classic/legacy DevMode. With GWT 
>>> 2.9.0 you have to use SuperDevMode to have a functional Java SDK emulation 
>>> during development.
>>>
>>> -- J.
>>>
>>> abhiy...@gmail.com schrieb am Mittwoch, 29. Juni 2022 um 21:58:40 UTC+2:
>>>
 Hi Team,

 I am trying to start classic DEV mode in eclipse through GWT eclipse 
 plugin .
 I am using GWT 2.9.0 + Java 11 combination.
 I am getting below error. Can you help me in resolving the below error:

 [b]Caused by: java.lang.ClassNotFoundException: javax.sql.DataSource
 at 
 com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload$WebAppClassLoaderExtension.findClass(JettyLauncher.java:478)
  
 ~[gwt-dev-2.9.0.jar:?]
 at 
 org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:441)
  

>>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-tool...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/6d3569b5-b7f0-4c2e-918c-c342b6803441n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/ca2662bc-f0ba-48f2-bd14-e673dd882ccdn%40googlegroups.com.

Re: unable to instal and use gwt-plugin in Eclipse 2022-06 or Eclipse 2022-09

[eliasbala...@gmail.com]

I am facing the same problems here, having teams of developers only 
familiar with the GWT plugin.

Unfortunately, the alternative is ratehr tricky.
To my understanding it involves use of Maven run configurations within 
Eclipse respective to the GWT plugin run configurations plus forcing 
"maven-install-plugin" to run within Eclipse.
see 
https://www.eclipse.org/m2e/documentation/release-notes-17.html#new-syntax-for-specifying-lifecycle-mapping-metadata

I am afraid GWT plugin is sadly leaving us.

I hope this helps you.

On Tuesday, 15 November 2022 at 16:34:09 UTC ngf.ch...@gmail.com wrote:

> I am using Eclipse IDE for Enterprise Java and Web Developers - 2022-09 
> and am unable to install and use gwt plugin.
> 1. I have before then used Eclipse IDE for Enterprise Java and Web 
> Developers - 2022-06 with the same result. The plugin doesn't install in 
> eclipse.
>
>
> How to use gwt now as i can't use it through my IDE.? 
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/13e4ac1b-efb1-4fa5-a89d-eb80bd6dbf5en%40googlegroups.com.

Re: JavaFX for GWT

[eliasbala...@gmail.com]

This is quite an interesting approach, I am intrigued.

Some remoting capabilities could be useful though.
I know a few standalone apps (Swing, SWT, JavaFX etc.) that rely on server 
communications.

Perhaps custom communication layers for various protocols and transports 
could be added by contributors.

On Wednesday, 9 November 2022 at 14:58:42 UTC Bruno Salmon wrote:

> hi Jonathan,
>
> Unfortunately for your project, I have no plan to support Swing as 
> covering JavaFX is already a big job.
>
> If you are looking for a solution to run your app without a server like 
> WebFX does, I don't think that exists for Swing.
>
> But if you don't mind having a server, there are solutions like WebSwing 
> that can run your app on a server, and then you can have a kind of remote 
> desktop of it in the browser. 
>
> On Wednesday, 9 November 2022 at 12:39:48 UTC Jonathan Franchesco Torres 
> Bca wrote:
>
>> Hi,
>>
>> And what about JFC Swing which is interoperable with JavaFX.
>> I have a desktop application that mixes both and we use substance to 
>> improve the display of the controls
>> I leave an example
>> [image: image.png]
>>
>>  
>>
>>  *   
>>    
>>  *
>>
>> Jonathan Franchesco Torres Baca(@jofrantoba)
>>
>> CIO - Kiongo Technology
>>
>> *Jr Juan Voto Bernales 344 - La Victoria, Lima - Perú*
>>
>> Teléfono   *+5116357857 <+51%201%206357857>*
>>
>> Cel.+51929913524 <+51%20929%20913%20524>
>>
>>
>> El mar, 8 nov 2022 a las 9:38, Bruno Salmon () 
>> escribió:
>>
>>> Hi,
>>>
>>> I'm working on a JavaFX transpiler powered by GWT.
>>> It lets you use JavaFX as a UI toolkit in your GWT apps.
>>> The JavaFX API is far from completely covered, but you can already see 
>>> some interesting results.
>>>
>>> The project is on GitHub for those who are interested.
>>> https://github.com/webfx-project/webfx
>>>
>>> If you have any questions, please let me know.
>>>
>>> -- 
>>>
>> You received this message because you are subscribed to the Google Groups 
>>> "GWT Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-web-tool...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit/8210a6a2-ad1a-4b2d-ba68-19dcc5fbeef3n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/72879326-af08-48da-8eaf-6cfee7bc85d3n%40googlegroups.com.

Re: Migrating to ltgt gwt-maven-plugin causes compile problem with HibernateValidation

[eliasbala...@gmail.com]

This looks like a classpath issue, from which I have suffered in the past 
but eventually managed to control.

I suggest using Maven dependency control to force the correct 
implementation of the offending classes, particularly if you are running 
with "GWT Eclipse Plugin" which doesn't respect inherited Maven dependency 
exclusions/overrides etc.

If you are using "GWT Eclipse Plugin", even though it is becoming outdated, 
there is still a way to control the classpath.
study https://github.com/eliasbalasis/eclipse-gwt-recipe for 
single-classpath for "Single CLASSPATH stream" traces.

I hope this helps you.

On Wednesday, 24 August 2022 at 03:42:59 UTC+1 Thomas wrote:

> Hi all,
>
> I'm in the progress of modularising a GWT app and migrating it to use the 
> newer ltgt gwt-maven-plugin. I have a GWT module which compiles correctly 
> using the old gwt-maven-plugin, but fails with the following errors using 
> the new gwt-maven-plugin:
>
> [INFO] --- gwt-maven-plugin:1.0.1:compile (default-compile) @ gwt-portal 
> ---
> [INFO] Compiling module com.inspectivity.portal.Portal
> [INFO]Tracing compile failure path for type 
> 'com.inspectivity.portal.client.validation.CustomValidatorFactory'
> [INFO]   [ERROR] Errors in 
> 'file:/Users/thomas/dev-private/inspectivity-modules/gwt-portal/src/main/java/com/inspectivity/portal/client/validation/CustomValidatorFactory.java'
> [INFO]  [ERROR] Line 31: The method getParameterNameProvider() of 
> type CustomValidatorFactory must override or implement a supertype method
> [INFO]  [ERROR] Line 36: The method close() of type 
> CustomValidatorFactory must override or implement a supertype method
> [INFO]Tracing compile failure path for type 
> 'org.hibernate.validator.engine.PathImpl'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/Users/thomas/.m2/repository/com/google/gwt/gwt-user/2.8.2/gwt-user-2.8.2.jar!/org/hibernate/validator/super/org/hibernate/validator/engine/PathImpl.java'
> [INFO]  [ERROR] Line 72: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 84: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 131: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 202: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 95: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 127: NodeImpl cannot be resolved to a type
> [INFO]Tracing compile failure path for type 
> 'org.hibernate.validator.engine.ConstraintViolationImpl_CustomFieldSerializer'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/Users/thomas/.m2/repository/com/google/gwt/gwt-user/2.8.2/gwt-user-2.8.2.jar!/org/hibernate/validator/engine/ConstraintViolationImpl_CustomFieldSerializer.java'
> [INFO]  [ERROR] Line 100: The method 
> instantiate(SerializationStreamReader) from the type 
> ConstraintViolationImpl_CustomFieldSerializer refers to the missing type 
> ConstraintViolationImpl
> [INFO]  [ERROR] Line 37: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 73: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 32: The type 
> ConstraintViolationImpl_CustomFieldSerializer must implement the inherited 
> abstract method 
> CustomFieldSerializer.deserializeInstance(SerializationStreamReader,
>  
> ConstraintViolationImpl)
> [INFO]  [ERROR] Line 33: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 32: The type 
> ConstraintViolationImpl_CustomFieldSerializer must implement the inherited 
> abstract method 
> CustomFieldSerializer.serializeInstance(SerializationStreamWriter,
>  
> ConstraintViolationImpl)
> [INFO]  [ERROR] Line 41: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 105: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 88: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 53: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]  [ERROR] Line 98: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]Tracing compile failure path for type 
> 'org.hibernate.validator.engine.ValidationSupport'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/Users/thomas/.m2/repository/com/google/gwt/gwt-user/2.8.2/gwt-user-2.8.2.jar!/org/hibernate/validator/engine/ValidationSupport.java'
> [INFO]  [ERROR] Line 43: ConstraintViolationImpl cannot be 
> resolved to a type
> [INFO]   [ERROR] Errors in 
> 'jar:file:/Users/thomas/.m2/repository/com/google/gwt/gwt-user/2.8.2/gwt-user-2.8.2.jar!/org/hibernate/validator/super/org/hibernate/validator/engine/PathImpl.java'
> [INFO]  [ERROR] Line 72: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 84: NodeImpl cannot be resolved to a type
> [INFO]  [ERROR] Line 131: NodeImpl cannot be resolved to a type
> [INFO]  

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[eliasbala...@gmail.com]

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 migration 
> from 
> Java 11 to 17 is in progress. So from my side, let's cut off the old 
> stuff. 
>
>
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/4996f471-8ed8-43af-9a88-96323483cf0an%40googlegroups.com.

Re: GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

This seems to be working finally.

To my surprise, I repeated the experiment and [GWT Eclipse Plugin] is fully 
accessible and operational.

I am now confused.

On Monday, 23 May 2022 at 23:37:41 UTC+1 hprc wrote:

>
> I also use the GWT Eclipse Plugin.
> Currently, the Eclipse side is up to 202103, and seems to be up to JDK1.8.
>
> The official documentation still only describes this plugin, so I'd like 
> you to add a method with the Moven plugin as soon as possible.
> (Preferably with illustrations)
> 2022年5月24日火曜日 6:57:01 UTC+9 eliasb...@gmail.com:
>
>> [GWT Eclipse Plugin] has served us very well.
>>
>> It is quite unfortunate but I fear the time for putting it to rest is 
>> approaching, if it hasn't already come.
>>
>> I just don't want to give up yet :-)
>>
>> On Monday, 23 May 2022 at 03:46:42 UTC+1 hprc wrote:
>>
>>>
>>> It's certainly interesting.
>>> However, do you recognize that the development of [GWT Eclipse Plugin] 
>>> will not be continued anymore?
>>> 2022年5月22日日曜日 18:16:34 UTC+9 eliasb...@gmail.com:
>>>
 Interesting...

 But you are using STS distribution not the standard, perhaps something 
 is different in the STS distribution compared to the primary Eclipse 
 Foundation's distribution.

 On Saturday, 14 May 2022 at 19:09:32 UTC+1 foal wrote:

> I am on Eclipse 4.22 (STS 4.13.1) and plugin still works (
> https://github.com/gwt-plugins/gwt-eclipse-plugin) 
>
> On Wednesday, May 4, 2022 at 12:56:47 AM UTC+2 Craig Mitchell wrote:
>
>> I'm on Eclipse 2021-09 (4.21.0) and it works fine.
>>
>> However, after this version, the Google plugin stops working  
>> https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3659  
>> so I haven't tried later versions.
>>
>> On Monday, 2 May 2022 at 11:17:23 pm UTC+10 eliasb...@gmail.com 
>> wrote:
>>
>>> Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still working.
>>>
>>> Under Eclipse 2022-03, the preferences page, the GWT Development 
>>> view and the run configurations are not accessible.
>>>
>>> This is crucial for certain teams relying on GWT Eclipse Plugin for 
>>> running applications from within the Eclipse IDE and locks users to 
>>> Eclipse 
>>> 2021-03 permanently, unless this can be fixed.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/3d2d5269-8d35-45d6-a7b7-0d549759bdf0n%40googlegroups.com.

Re: GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

[GWT Eclipse Plugin] has served us very well.

It is quite unfortunate but I fear the time for putting it to rest is 
approaching, if it hasn't already come.

I just don't want to give up yet :-)

On Monday, 23 May 2022 at 03:46:42 UTC+1 hprc wrote:

>
> It's certainly interesting.
> However, do you recognize that the development of [GWT Eclipse Plugin] 
> will not be continued anymore?
> 2022年5月22日日曜日 18:16:34 UTC+9 eliasb...@gmail.com:
>
>> Interesting...
>>
>> But you are using STS distribution not the standard, perhaps something is 
>> different in the STS distribution compared to the primary Eclipse 
>> Foundation's distribution.
>>
>> On Saturday, 14 May 2022 at 19:09:32 UTC+1 foal wrote:
>>
>>> I am on Eclipse 4.22 (STS 4.13.1) and plugin still works (
>>> https://github.com/gwt-plugins/gwt-eclipse-plugin) 
>>>
>>> On Wednesday, May 4, 2022 at 12:56:47 AM UTC+2 Craig Mitchell wrote:
>>>
 I'm on Eclipse 2021-09 (4.21.0) and it works fine.

 However, after this version, the Google plugin stops working  
 https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3659  
 so I haven't tried later versions.

 On Monday, 2 May 2022 at 11:17:23 pm UTC+10 eliasb...@gmail.com wrote:

> Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still working.
>
> Under Eclipse 2022-03, the preferences page, the GWT Development view 
> and the run configurations are not accessible.
>
> This is crucial for certain teams relying on GWT Eclipse Plugin for 
> running applications from within the Eclipse IDE and locks users to 
> Eclipse 
> 2021-03 permanently, unless this can be fixed.
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/5cf6e36d-dabe-46fb-b5e1-2913e0f33e02n%40googlegroups.com.

Re: GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

Interesting...

But you are using STS distribution not the standard, perhaps something is 
different in the STS distribution compared to the primary Eclipse 
Foundation's distribution.

On Saturday, 14 May 2022 at 19:09:32 UTC+1 foal wrote:

> I am on Eclipse 4.22 (STS 4.13.1) and plugin still works (
> https://github.com/gwt-plugins/gwt-eclipse-plugin) 
>
> On Wednesday, May 4, 2022 at 12:56:47 AM UTC+2 Craig Mitchell wrote:
>
>> I'm on Eclipse 2021-09 (4.21.0) and it works fine.
>>
>> However, after this version, the Google plugin stops working  
>> https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3659  
>> so I haven't tried later versions.
>>
>> On Monday, 2 May 2022 at 11:17:23 pm UTC+10 eliasb...@gmail.com wrote:
>>
>>> Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still working.
>>>
>>> Under Eclipse 2022-03, the preferences page, the GWT Development view 
>>> and the run configurations are not accessible.
>>>
>>> This is crucial for certain teams relying on GWT Eclipse Plugin for 
>>> running applications from within the Eclipse IDE and locks users to Eclipse 
>>> 2021-03 permanently, unless this can be fixed.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/1e5baf0b-9bc2-437d-bfbf-71644abd0299n%40googlegroups.com.

GWT Eclipse Plugin is not compatible with Eclipse 2022-03

[eliasbala...@gmail.com]

Until Eclipse 2021-03 (4.19) the GWT Eclipse Plugin is still working.

Under Eclipse 2022-03, the preferences page, the GWT Development view and 
the run configurations are not accessible.

This is crucial for certain teams relying on GWT Eclipse Plugin for running 
applications from within the Eclipse IDE and locks users to Eclipse 2021-03 
permanently, unless this can be fixed.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e165100e-7e7b-4439-927c-29448fc9f6b0n%40googlegroups.com.

Re: [gwt-contrib] Re: GWT 2.10 release?

[eliasbala...@gmail.com]

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 merge we need the 
> apichecker updated, and after that merges, we can remove the poorly 
> performing java.util.Date.fixDaylightSavings call. Likewise before 
> htmlunit/jetty can be upgraded, Java 7 support must be dropped and the new 
> jars put in the tools repo.
>
> Here are reviews currently waiting for someone to take a look:
>
>- Fix Chrome+SDM stack traces 
>https://gwt-review.googlesource.com/c/gwt/+/23500
>- Fix Chrome -XmethodDisplayName 
>https://gwt-review.googlesource.com/c/gwt/+/23580
>- Provide GWT 2.9.0 apicheck jars 
>https://github.com/gwtproject/tools/pull/22
>- Permit GWT 2.10.0 breaking api changes 
>https://gwt-review.googlesource.com/c/gwt/+/23680 (depends on tools#22)
>- Drop support for Java 7 
>https://gwt-review.googlesource.com/c/gwt/+/23700
>
> After these start to land (to avoid too many at a time), will be the 
> following:
>
>- Drop IE8/9/10 support (depends on review 23680 above)
>- Improve java.util.Date performance in both gwt2 and j2cl (depends on 
>dropping IE8/9)
>- Add latest HtmlUnit/Jetty to gwtproject/tools
>- Update Htmlunit/Jetty to latest (depends on dropping java7 support 
>and htmlunit/jetty being in tools) - this is somewhat incomplete, there 
> are 
>two dev mode tests that are failing, and jetty-env.xml is not presently 
>loaded correctly
>- Add Github Actions support - this depends on the patch which drops 
>Java 7 support due to some issue in running the validation tests in that 
>environment. I'm attempting to replicate build.gwtproject.org except 
>in a way that is visible, and can deploy snapshots to the org.gwtproject 
>groupId when we're ready for that.
>
> If you have +2 permissions in the review site, I'd appreciate a look at 
> some of these, if you are interested in trying out the patches and giving a 
> +1 that would help other reviewers as well.
>
> On Tuesday, October 12, 2021 at 8:01:02 AM UTC-5 juan_pablo_gardella wrote:
>
>> @co...@colinalworth.com  do yo know any ETA on this?
>>
>> On Tue, Oct 12, 2021, 5:28 AM Rocco De Angelis  
>> wrote:
>>
>>>
>>> Nice +1 
>>> chani...@gmail.com schrieb am Dienstag, 5. Oktober 2021 um 16:38:08 
>>> UTC+2:
>>>
 Thank a millon, looks great ! +1

 On Friday, October 1, 2021 at 2:55:21 p.m. UTC-4 krypto...@gmail.com 
 wrote:

> awesome +1
>
> On Fri, Oct 1, 2021 at 2:31 PM mcmi...@gmail.com  
> wrote:
>
>> Sound greats +1
>>
>>
>> nilo...@gmail.com schrieb am Donnerstag, 30. September 2021 um 
>> 21:22:13 UTC+2:
>>
>>> We've got a few changes that have been brewing or waiting to be made 
>>> available, and it sounds like it is about time to collectively push to 
>>> make 
>>> these things happen. Given the nature of some of these, I am suggesting 
>>> that they not be folded into a bugfix release, but instead that the 
>>> next 
>>> release be 2.10.0.
>>>
>>>
>>> Changing Maven Central groupId
>>> One of the big ones is work to migrate off of the "com.google.gwt" 
>>> groupId (note that we are not adjusting packages) and into our own 
>>> namespace in maven, "org.gwtproject.gwt". Google's efforts to open 
>>> sourcing 
>>> and encourage GWT has been very accommodating for the community, and 
>>> this 
>>> change is long past due, so that releases of GWT do not need someone 
>>> with 
>>> access to the com.google groupId in Maven Central to perform the 
>>> release 
>>> process for us. If successful, this will be the final release which 
>>> uses 
>>> the old groupId. 
>>>
>>> To that end, Thomas Broyer has done a lot of work to make sure this 
>>> path will be as smooth as possible. That work can be seen discussed 
>>> in the mailing list 
>>> 
>>>  
>>> and in a github repo he wrote 
>>>  to demonstrate 
>>> approaches and their relative merits. No final summary was officially 
>>> posted, but from discussions in gitter chat 
>>> , the 
>>> cleanest proposed option is to follow Experiment #3 for today, and 
>>> optionally later to roll out the last two options to more easily 
>>> facilitate 
>>> updates from older releases.
>>>
>>> This means that the next release will be performed first on 
>>> org.gwtproject, and then later we will request that someone at Google 
>>> perform the final 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Tuesday, 4 May 2021 at 16:54:45 UTC+1 t.br...@gmail.com wrote:

> On Tue, May 4, 2021 at 10:20 AM 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/ 
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c72dd752-4fff-41d8-ab18-3fc473d56e2fn%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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

On Tuesday, 4 May 2021 at 16:29:45 UTC+1 lofid...@gmail.com wrote:

> @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 schrieb am Dienstag, 4. Mai 2021 um 10:20:53 UTC+2:
>
>> 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.
>>
>> On Tuesday, 4 May 2021 at 08:53:21 UTC+1 t.br...@gmail.com wrote:
>>
>>> 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 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Tuesday, 4 May 2021 at 08:53:21 UTC+1 t.br...@gmail.com wrote:

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

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Monday, 19 April 2021 at 11:52:05 UTC+1 bernhar...@schubec.com wrote:

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

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/cb114439-2b29-485b-bca1-c756df176f69n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Monday, 19 April 2021 at 10:16:25 UTC+1 Gordan Krešić wrote:

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

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/8d22b337-a38b-46e3-9200-2f734dcd778cn%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Sunday, 18 April 2021 at 23:30:26 UTC+1 Paul Robinson wrote:

> On Sat, Apr 17, 2021 at 7:45 PM 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
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bbf47e78-25c5-4b49-9e50-3ebed00d05a4n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Sunday, 18 April 2021 at 18:35:11 UTC+1 t.br...@gmail.com wrote:

> On Sun, Apr 18, 2021 at 6:29 PM 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/ 
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/aa8830b3-d6d3-4e5d-adc0-fdb61c2bb293n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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

On Sunday, 18 April 2021 at 16:41:02 UTC+1 t.br...@gmail.com wrote:

> On Sun, Apr 18, 2021 at 3:16 PM 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.
>
>  
>
>>
>> On Sunday, 18 April 2021 at 13:33:15 UTC+1 t.br...@gmail.com wrote:
>>
>>> 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 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Sunday, 18 April 2021 at 13:33:15 UTC+1 t.br...@gmail.com wrote:

> On Sat, Apr 17, 2021 at 10:07 PM 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. 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Saturday, 17 April 2021 at 20:32:13 UTC+1 t.br...@gmail.com wrote:

>
>
> Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon  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.
>
>
>>
>>
>>   
>>
>> Jonathon Lamon
>>
>> DevOps Manager / Principal Engineer Special Projects
>> Perceptronics Solutions Inc.
>> Cell 269-205-4649 <(269)%20205-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 
>> *Subject:* Re: [gwt-contrib] Asking for decision on DevMode embedded 
>> Jetty support 
>>  
>>
>> CAUTION -- EXTERNAL E-MAIL
>> 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.
>>
>> On Saturday, 17 April 2021 at 19:36:18 UTC+1 t.br...@gmail.com wrote:
>>
>> 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.
>>
>> Le sam. 17 avr. 2021 à 20:06, eliasb...@gmail.com  
>> a écrit :
>>
>> This feels much better now. 
>>
>> Serving only static GWT client-side via DevMode+Jetty sounds good.
>>
>> We could run the 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Saturday, 17 April 2021 at 19:36:18 UTC+1 t.br...@gmail.com wrote:

> 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.
>
> Le sam. 17 avr. 2021 à 20:06, eliasb...@gmail.com  a 
> écrit :
>
>> 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 t.br...@gmail.com wrote:
>>
>>> 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.
>>>
>>> Le sam. 17 avr. 2021 à 19:34, eliasb...@gmail.com  
>>> a écrit :
>>>
 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 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
>
 -- 

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

>>> -- 
>> 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/94c5c53d-b72a-4887-a617-4d1064c7c8fan%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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-contributors+unsubscr...@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.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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?

On Saturday, 17 April 2021 at 18:45:39 UTC+1 t.br...@gmail.com wrote:

> 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.
>
> Le sam. 17 avr. 2021 à 19:34, eliasb...@gmail.com  a 
> écrit :
>
>> 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 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
>>>
>> -- 
>>
> 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
>>  
>> 
>> .
>>
>

-- 
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-contributors+unsubscr...@googlegroups.com.
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.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Saturday, 17 April 2021 at 17:25:19 UTC+1 Paul Robinson wrote:

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

-- 
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-contributors+unsubscr...@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.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Saturday, 17 April 2021 at 14:58:37 UTC+1 bernhar...@schubec.com wrote:

> 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  
>> 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 <+43%20699%2019337476>
> 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
>
>

-- 
You received this message because you are subscribed to the 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

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  
> 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-contributors+unsubscr...@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.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Tuesday, 13 April 2021 at 19:01:04 UTC+1 ric...@gmail.com wrote:

> 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.
> On 2021-04-11 9:15 a.m., Jens wrote:
>
> 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.
>
> -- 
> 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
>  
> 
> .
>
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/4040caf5-5a05-4722-a971-b684aea5dcb4n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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"

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.
>
> Le mar. 13 avr. 2021 à 21:01, Richi Plana  a écrit :
>
>> 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. 
>>
>> On Tue., Apr. 13, 2021, 12:04 Thomas Broyer,  wrote:
>>
>>> Which features are you talking about? Which would you lose by switching 
>>> to using a *real* Jetty server alongside GWT CodeServer?
>>>
>>> Le mar. 13 avr. 2021 à 20:01, Richi Plana  a écrit :
>>>
 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.
 On 2021-04-11 9:15 a.m., Jens wrote:

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

 -- 
 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/c317be1c-55d9-f255-0b0f-e05da19240ee%40gmail.com
  
 
 .

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and 

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@gmail.com]

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

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e7bc5b01-4794-4297-bc89-a21319041389n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@gmail.com]

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 development (for dev purposes). My 
> understanding is that it's a choice of bumping up Java version or losing 
> Jetty. 
>
> On Tue., Apr. 13, 2021, 12:04 Thomas Broyer,  wrote:
>
>> Which features are you talking about? Which would you lose by switching 
>> to using a *real* Jetty server alongside GWT CodeServer?
>>
>> Le mar. 13 avr. 2021 à 20:01, Richi Plana  a écrit :
>>
>>> 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.
>>> On 2021-04-11 9:15 a.m., Jens wrote:
>>>
>>> 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.
>>> -- 
>>> 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
>>>  
>>> 
>>> .
>>>
>>> -- 
>>> 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/c317be1c-55d9-f255-0b0f-e05da19240ee%40gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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/CAEayHEOAgJFjDiacN7w31ASa3pg8bL%2B0mEOc1Q7Sy1cdCtTd4w%40mail.gmail.com
>>  
>> 
>> .
>>
>

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

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@gmail.com]

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 development (for dev purposes). My 
> understanding is that it's a choice of bumping up Java version or losing 
> Jetty. 
>
> On Tue., Apr. 13, 2021, 12:04 Thomas Broyer,  wrote:
>
>> Which features are you talking about? Which would you lose by switching 
>> to using a *real* Jetty server alongside GWT CodeServer?
>>
>> Le mar. 13 avr. 2021 à 20:01, Richi Plana  a écrit :
>>
>>> 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.
>>> On 2021-04-11 9:15 a.m., Jens wrote:
>>>
>>> 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.
>>> -- 
>>> 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
>>>  
>>> 
>>> .
>>>
>>> -- 
>>> 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/c317be1c-55d9-f255-0b0f-e05da19240ee%40gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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/CAEayHEOAgJFjDiacN7w31ASa3pg8bL%2B0mEOc1Q7Sy1cdCtTd4w%40mail.gmail.com
>>  
>> 
>> .
>>
>

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

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@gmail.com]

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.
>
> 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.
>
> On Tuesday, 13 April 2021 at 19:19:23 UTC+1 frank.h...@googlemail.com 
> wrote:
>
>> @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.
>>
>>
>> t.br...@gmail.com schrieb am Dienstag, 13. April 2021 um 20:04:04 UTC+2:
>>
>>> Which features are you talking about? Which would you lose by switching 
>>> to using a *real* Jetty server alongside GWT CodeServer?
>>>
>>> Le mar. 13 avr. 2021 à 20:01, Richi Plana  a écrit :
>>>
>>>> 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.
>>>> On 2021-04-11 9:15 a.m., Jens wrote:
>>>>
>>>> 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.
>>>> -- 
>>>> 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
>>>>  
&

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Tuesday, 13 April 2021 at 19:19:23 UTC+1 frank.h...@googlemail.com wrote:

> @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.
>
>
> t.br...@gmail.com schrieb am Dienstag, 13. April 2021 um 20:04:04 UTC+2:
>
>> Which features are you talking about? Which would you lose by switching 
>> to using a *real* Jetty server alongside GWT CodeServer?
>>
>> Le mar. 13 avr. 2021 à 20:01, Richi Plana  a écrit :
>>
>>> 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.
>>> On 2021-04-11 9:15 a.m., Jens wrote:
>>>
>>> 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.
>>> -- 
>>> 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
>>>  
>>> 
>>> .
>>>
>>> -- 
>>> 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/c317be1c-55d9-f255-0b0f-e05da19240ee%40gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

[gwt-contrib] Re: Asking for decision on DevMode embedded Jetty support

[eliasbala...@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.

On Tuesday, 13 April 2021 at 16:16:51 UTC+1 frank.h...@googlemail.com wrote:

> 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. 
>
>  
>
>
> Jens schrieb am Sonntag, 11. April 2021 um 23:04:13 UTC+2:
>
>> 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
>>
>>
>>
>>
>>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/60735ae0-d52e-4282-aeef-2ec6ffe2ad64n%40googlegroups.com.

Eclipse Plugin WebContent Refresh

[eliasbala...@gmail.com]

I am quite successfully using Google Eclipse Plugin for GWT with
Eclipse J2EE 3.5 (Galileo) release

Only issue I have is with automatic refresh of WebContent folder.
Under an Eclipse WTP project the default folder for generating web
files is WebContent. default for google plugin in war.
I changed google plugin's default but when compiling Eclipse does not
seem to refresh the contents of the output folder and thus WTP cannot
republish the output to running web server. (I had to do it manually
or semi-automatically using an eclipse external tool configuration
with ant)

Is it possible to consider implementing the refresh in future versions
of google plugin? Plugin works perfectly under eclipse. It is just a
matter of convenience and easier project maintenance.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---