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 [email protected] wrote:

> On Sun, Apr 18, 2021 at 3:16 PM [email protected] <[email protected]> 
> 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 [email protected] wrote:
>>
>>> On Sat, Apr 17, 2021 at 10:07 PM [email protected] <
>>> [email protected]> wrote:
>>>
>>>> OK, I guess not many people have used this technique.
>>>>
>>>
>>> This is what we're advocating for years: separate your client and server 
>>> code, run the server code in one server, run the client code with "DevMode 
>>> -noserver" or "CodeServer -launcherDir".
>>> I started gwt-maven-archetypes with that technique 9 years ago this 
>>> month, and have been advocating this since then: 
>>> http://blog.ltgt.net/announcing-gwt-maven-archetypes-project/
>>> This was even before SuperDevMode was a thing (and I was using this 
>>> project layout at work for nearly 2 years already).
>>> And as I linked earlier, GWT Eclipse Plugin supports this for years too (
>>> https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/Tomcat.html;
>>>  
>>> the Youtube videos date back to Nov 2016)
>>>  
>>>
>>>> So, I will try explaining this in a different way.
>>>>
>>>> Indeed, DevMode runs a CodeServer itself.
>>>>
>>>> We have a GWT Maven project and we run it using the "DevMode" runner of 
>>>> "Google Plugin for Eclipse", in a single step, instead of running 
>>>> CodeServer and servlet container separately etc.
>>>>
>>>
>>> Do you really mean "Google Plugin for Eclipse"?
>>> Because it's been dead for quite a while (
>>> https://cloud.google.com/eclipse/docs/migrating-gpe / 
>>> https://github.com/GoogleCloudPlatform/google-cloud-eclipse/wiki/Migrating-from-the-Google-Plugin-for-Eclipse),
>>>  
>>> replaced by Cloud Tools for Eclipse (from Google) and GWT Eclipse Plugin 
>>> (single-handedly maintained by Brandon Donnelson, from the original Google 
>>> Plugin for Eclipse source code, but Brandon no longer does much GWT as 
>>> Sencha, his employer, silently moved away from it a couple years ago)
>>> Google Plugin for Eclipse does not support Eclipse 4.7 (Oxygen), which 
>>> was released in the summer 2017.
>>>  
>>>
>>>> This starts DevMode (with internal codeserver) and a Jetty server on a 
>>>> given TCP port.
>>>>
>>>> When accessing the application from a browser, DevMode compiles the GWT 
>>>> client-code at runtime and delivers it to the browser (no separate 
>>>> codeserver, no separate servlet container etc.)
>>>>
>>>> >> Same with CodeServer with -launcherDir, or DevMode with -noserver
>>>> This is equivalent to DevMode without "noserver".
>>>>
>>>> >> What would be the workflow with DevMode serving only static files, 
>>>> and servlets deployed separately?
>>>> The workflow would be the same, it is just the GWT client-side code 
>>>> wouldn't know how to access the server-side code.
>>>>
>>>
>>> The same as what?
>>> Sorry but I want to make sure we clearly understand each other.
>>> If you're saying that the workflow would be the same as what you're 
>>> describing above, then I don't understand: you're deploying servlets 
>>> separately, so you at least need an additional step to do that.
>>> If you're saying it's the same as what you described earlier (and quoted 
>>> below), then I don't understand why you said “We could run the GWT 
>>> server-side only code separately, not a problem at all.”
>>>
>>> Here's what the workflow is/should be for many/most people:
>>>
>>>    - if you're using an IDE with special GWT support (GWT Eclipse 
>>>    Plugin; IntelliJ IDEA Ultimate), then it's just one click; launches both 
>>> a 
>>>    servlet where your webapp is deployed, and the CodeServer (or DevMode 
>>>    -noserver) for your client code. Similar things are available in some 
>>>    Gradle plugins. I don't know much more as I don't use any of those.
>>>    - otherwise:
>>>       1. launch a server where you webapp is deployed; it should be 
>>>       able to serve static resources from a given directory
>>>       2. launch CodeServer (or DevMode -noserver) with -launcherDir (or 
>>>       -war) pointing to the directory where your static resources are 
>>> served from
>>>       3. *there's no third step*; open your webapp (possibly with the 
>>>       help of DevMode's -startupUrl) and upon loading the nocache.js 
>>> (generated 
>>>       by GWT at launch of step 2, served from the server in step 1) it'll 
>>> compile 
>>>       your client code on the fly. Everything works *exactly* the same 
>>>       as with DevMode and the embedded webapp server; with the difference 
>>> that 
>>>       your server-side code is in another server so re-deploying it works 
>>>       differently (depends on that server then, and tooling around it)
>>>    
>>> This is actually (almost) the same as if you used a JS toolchain in 
>>> "watch" mode. If you'd prefer something more like a "devserver" (à la 
>>> webpack-dev-server) which would proxy requests to your backend, then I had 
>>> started https://github.com/tbroyer/gwt-devserver which never gained 
>>> traction; feel free to fork it, it's under the rather liberal Apache 2.0 
>>> license.
>>>
>>> I hope this explains things better.
>>>>
>>>> On Saturday, 17 April 2021 at 20:32:13 UTC+1 [email protected] wrote:
>>>>
>>>>>
>>>>>
>>>>> Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon <[email protected]> 
>>>>> 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:* [email protected] <
>>>>>> [email protected]> on behalf of [email protected] 
>>>>>> <[email protected]>
>>>>>> *Sent:* Saturday, April 17, 2021 2:45:35 PM
>>>>>> *To:* GWT Contributors <[email protected]>
>>>>>> *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 [email protected] 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, [email protected] <
>>>>>> [email protected]> 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 [email protected] 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, [email protected] <
>>>>>> [email protected]> 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 [email protected].
>>>>>>
>>>>>> 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
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/9cce0909-56fc-4804-a032-103184c05af1n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> -- 
>>>>>> 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 [email protected].
>>>>>>
>>>>>> 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
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/94c5c53d-b72a-4887-a617-4d1064c7c8fan%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> -- 
>>>>>> You received this message because you are subscribed to a topic in 
>>>>>> the Google Groups "GWT Contributors" group.
>>>>>> To unsubscribe from this topic, visit 
>>>>>> https://groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>>> [email protected].
>>>>>> 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
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4486df4d-553d-409f-b3a8-4b4887ff0b9fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments 
>>>>>> unless you recognize the sender.
>>>>>>
>>>>>> ------------------------------
>>>>>> The content of this email is confidential and intended for the 
>>>>>> recipient specified in message only. It is strictly forbidden to share 
>>>>>> any 
>>>>>> part of this message with any third party, without a written consent of 
>>>>>> the 
>>>>>> sender. If you received this message by mistake, please reply to this 
>>>>>> message and follow with its deletion, so that we can ensure such a 
>>>>>> mistake 
>>>>>> does not occur in the future. 
>>>>>>
>>>>>> -- 
>>>>>> 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 [email protected].
>>>>>>
>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/BN3P110MB0354A199D56BBA0158B8D7E2DC4B9%40BN3P110MB0354.NAMP110.PROD.OUTLOOK.COM
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/BN3P110MB0354A199D56BBA0158B8D7E2DC4B9%40BN3P110MB0354.NAMP110.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> -- 
>>>> 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 [email protected].
>>>>
>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ab443c9-cfea-4d63-8cfe-90311cab0c64n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4ab443c9-cfea-4d63-8cfe-90311cab0c64n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Thomas Broyer
>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "GWT Contributors" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected].
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8936a38c-7bce-4351-89e5-aab0cd9ab662n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/8936a38c-7bce-4351-89e5-aab0cd9ab662n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5a068bec-8f5d-4456-a723-66aa168f776cn%40googlegroups.com.

Reply via email to