Is it correct to say that I have to have a separate class path specifically
for running SuperDev so that Jetty will function properly? Or is there some
way to launch Super Dev without interacting with Jetty at all? My
application compiles and launches just fine with Tomcat 10.1 + Spring 6,
but Super Dev won't launch due to compatibility issues with Jakarta Servlet
6 and Jetty 9.
Unfortunately, it's very difficult for me to configure a separate class
path specifically to run Super Dev with a lower servlet spec due to the
size of this application and intertwining of client and server classes. It
quite honestly might be faster to just try and upgrade the Super Dev code
to use a new version of Jetty that works with Jakarta 6.
On Friday, March 14, 2025 at 4:21:25 AM UTC-5 tekkyru wrote:
> When I switched to Gradle I had to leave GWT plugin behind on advice of
> other users here, and it was good. Finally I have decoupled classpaths of
> my app, GWT, GWT plugin and Jetty (latter 2 are never used anymore).
>
> For that I have created a GWT dev server launch task for my configuration:
> Gradle, Eclipse, GWT, Tomcat. It can be sub-optimal (to say the least) as
> it was my first Gradle project.
>
> I have my webapp project in Eclipse, I have set up the Eclipse Tomcat
> server for it, I launch it normally (run or debug) and I launch this Gradle
> task as an Eclipse external tool (or could be done from console):
>
> gradlew.bat gwtCodeServer -PworkspaceDir=${workspace_loc}
>
> The quoted task unfortunately is not runnable as is, it's an excerpt from
> a complex project. I hope it can give ideas or even be adjusted to be
> runnable from your build script.
>
> Please note the gwtToolsClasspath at the end:
> - it's not provided by default, I'm sorry I cannot provide a workable
> state for this post now,
> it's a configuration that refers GWT tools and all your GWT-related java
> and resources (as GWT compiler looks them up in classpath).
>
> At least it includes
> "${gwtPomBase}:gwt-dev:${gwtVersion}"
> "${gwtPomBase}:gwt-codeserver:${gwtVersion}"
>
> --------------------------------------------------------
>
> task gwtCodeServer(type: JavaExec) {
>
> description = 'Run the GWT code server for Super Dev Mode'
>
> def workDir = "$buildDir/tmp/gwt"
>
> mainClass = 'com.google.gwt.dev.codeserver.CodeServer'
>
> jvmArgs = ['-Xmx1g', '-Dfile.encoding=UTF-8']
>
> doFirst {
> def wspServerPluginDir = file(project.getProperty("workspaceDir") +
> "/.metadata/.plugins/org.eclipse.wst.server.core")
>
> if(!wspServerPluginDir.isDirectory()) {
> throw new GradleException("Not a directory: ${wspServerPluginDir}\n"
> +"Workspace referenced by 'workspaceDir' project dir does not exist "
> +" or it has no 'org.eclipse.wst.server.core' configured yet")
> }
>
>
> def webAppDirs = []
> file(wspServerPluginDir).eachFileMatch groovy.io.FileType.DIRECTORIES,
> { new File(wspServerPluginDir, "${it}/wtpwebapps/${
> rootProject.projectDir.name}").isDirectory() }, {
> webAppDirs.add it
> }
>
> if(webAppDirs.size() == 0) {
> throw new GradleException("Webapp ${rootProject.projectDir.name} is not
> yet deployed, publish it in Tomcat at least once")
> } else if(webAppDirs.size() > 1) {
> throw new GradleException("There are several webapp dirs deployed for same
> webapp ${rootProject.projectDir.name}, inconsistent state")
> }
>
> def gwtTargetDir = "${webAppDirs[0]}/wtpwebapps/${
> rootProject.projectDir.name}"
> args = []
> args += ['-launcherDir', gwtTargetDir, '-workDir', workDir]
> args += ['-logLevel', 'INFO', '-style', 'DETAILED', '-sourceLevel',
> '17', '-port', '9876']
> args += [__INSERT_MODULE_NAME__]
>
> println "Run GWT Code Server: " + args
> classpath.from gwtToolsClasspath
> file(workDir).mkdirs()
> }
> }
>
> On Thursday, March 13, 2025 at 11:01:34 PM UTC+1 Dyllan Sowers wrote:
>
>> I've very recently been exposed to GWT, so I apologize if any of the
>> following doesn't make sense.
>>
>> The project is split up, with the GWT XML at the top level alongside the
>> SpringBootApplication launcher class and client and server packages. The
>> application itself is launched with Spring's bootRun + Tomcat, and
>> historically developers used GWT's integrated Super Dev jetty servlet with
>> Eclipse and IntelliJ's GWT plugins. The 'org.docstr.gwt' version '1.1.30'
>> Gradle plugin was being used to compile and launch super dev, and I would
>> like to continue to use it to compile since attempting to compile directly
>> with Gradle tasks invoking the SDK fails without any helpful information.
>> I've determined that is a class path size issue, and the v1 org.docstr.gwt
>> Gradle plugin sets up the class path in a way that works much better with
>> this project (it's multi-Gradle-module and gargantuan, I'd rather not delve
>> into that).
>>
>> Is what I need to do to launch the server the way it typically is (with
>> Tomcat) and then invoke the com.google.gwt.dev.codeserver.CodeServer class
>> via a Gradle task? Or com.google.gwt.dev.DevMode with superDev enabled and
>> noServer?
>>
>> I have not gotten anything else to work yet. Any recommendations are
>> greatly appreciated.
>> On Wednesday, March 12, 2025 at 6:09:45 PM UTC-5 Michael Conrad wrote:
>>
>>> Are you using gradle :appRun or gradle :farmRun?
>>>
>>> Is your project split up into top level + server + shared + client? or
>>> just client? or all merged together?
>>>
>>> We also use the “farm” option in the top level project to launch
>>> backends + frontends on the same instance of TomCat each with its own
>>> context path based on war name.
>>>
>>> -Mike
>>>
>>> On 3/12/25 16:24, Dyllan Sowers wrote:
>>>
>>> I should elaborate, the main issue I'm running into is having to do with
>>> upgrading to Spring 6 / Jakarta Servlet 6. I'm trying to use either Tomcat
>>> 10.1 or Jetty 11 to launch the container service with Gradle tasks and the
>>> org.docstr.gwt:1.1.30 plugins and org.gretty:4.1.6 plugins with GWT 2.12.1.
>>> I've tried many different combinations of configurations and plugins, but
>>> ultimately run into this error every time:
>>> java.lang.NoClassDefFoundError:
>>> org/eclipse/jetty/server/handler/ContextHandler$Context
>>>
>>> On Wednesday, March 12, 2025 at 3:01:50 PM UTC-5 Dyllan Sowers wrote:
>>>
>>>> Thanks for the suggestion, Michael. Do you know of any examples of
>>>> anyone successfully doing this? I've found one older example but have been
>>>> running into issues trying to port it over to a more recent Jetty plugin
>>>> and Gradle version.
>>>> https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-gwt/build.gradle
>>>>
>>>> On Tuesday, March 11, 2025 at 1:09:36 PM UTC-5 Michael Conrad wrote:
>>>>
>>>>> You might want to look into using Gradle Gretty plugin for the
>>>>> container service in combination with starting up SuperDevMode via
>>>>> command
>>>>> line.
>>>>>
>>>>> On 3/11/25 12:41, Dyllan Sowers wrote:
>>>>>
>>>>> Does anyone have an example of how to setup the embedded server with
>>>>> dev mode, or even better, super dev mode? I'm upgrading a large
>>>>> Gradle-based enterprise application from Spring 5 to Spring 6 and
>>>>> migrated
>>>>> from javax to jakarta and have had constant issues from Jetty's
>>>>> compatibility problems.
>>>>>
>>>>> Any pointers would be a tremendous help. I'm currently trying to use
>>>>> tomcat-catalina-10.1 as the embedded server but have not been able to get
>>>>> it to start properly.
>>>>>
>>>>> On Monday, June 17, 2024 at 9:09:58 PM UTC-5 Craig Mitchell wrote:
>>>>>
>>>>>> It's when you see crazy long command lines like that, you start to
>>>>>> appreaciate Maven (or Gradle). The same command in Maven is "mvn
>>>>>> gwt:codeserver -pl *-client" (yes, I know you see still need to
>>>>>> setup the launcherDir, warDir, etc in the pom.xml files, but that seems
>>>>>> much easier than one huge command line).
>>>>>>
>>>>>> On Tuesday 18 June 2024 at 2:17:26 am UTC+10 Jens wrote:
>>>>>>
>>>>>>> > If using maven... [I'm not]... If not, please give us more detail
>>>>>>> about what you are using (or intend to use).
>>>>>>> After further investigation, much of my issues around this seem to
>>>>>>> be that the. appropriate java command to run the web app (or Jetty
>>>>>>> itself)
>>>>>>> is not being assembled correctly by either Eclipse, the GWT plugin, or
>>>>>>> both. There are various options that are needed and are not properly
>>>>>>> set.
>>>>>>> That said, even if I do/can get that working, I don't think that's the
>>>>>>> right approach. As you're going to deprecate the embedded Jetty
>>>>>>> server, I
>>>>>>> should do whatever is needed there to run my own external server(s).
>>>>>>> That's what's unclear to me. There are ancient references to it in
>>>>>>> the
>>>>>>> documentation at gwt.project.org, but I'm unclear on what is really
>>>>>>> needed. Do I need to set up and run a code server with my own Jetty or
>>>>>>> Tomcat local installation? If so, how is that set up? Or do I need to
>>>>>>> run
>>>>>>> my own app server (again, either Jetty or Tomcat). The web app setup
>>>>>>> is
>>>>>>> obvious (I think... or are there special runtime parameters to direct
>>>>>>> it to
>>>>>>> the proper code server port?). Forgive my ignorance on this, but if
>>>>>>> this
>>>>>>> is the path forward for GWT in general, I'd really like to see some
>>>>>>> clear
>>>>>>> documentation on how to set this up or at least what it is going to
>>>>>>> look
>>>>>>> like (in general, no specifics, obviously it should involve thinking
>>>>>>> and
>>>>>>> work on my part). Last note: I am assuming the code server will be
>>>>>>> easier
>>>>>>> to get working with Java 17 modules because it will (in my case) have
>>>>>>> less
>>>>>>> jar dependencies, as it only needs them for shared and client code.
>>>>>>> That
>>>>>>> said... I might need to run both externally to get it all sorted out.
>>>>>>> Again, my own thinking on this isn't that clear because I'm not in the
>>>>>>> weeds enough on what the plugin is really doing and how things work
>>>>>>> under
>>>>>>> the hood.
>>>>>>>
>>>>>>> To give a shorter, more direct answer: I want to develop code in
>>>>>>> Eclipse in Java 17, and be able to run the code server and web app any
>>>>>>> way
>>>>>>> possible, so that GWT code compiles/recompiles as needed, and the web
>>>>>>> app
>>>>>>> can be accessed in the browser, and I can do iterative
>>>>>>> test-code-test-code
>>>>>>> development on a daily basis.
>>>>>>>
>>>>>>>
>>>>>>> Traditionally GWT SDK only had the class com.google.gwt.dev.DevMode.
>>>>>>> It is responsible to launch classic dev mode (the one that does require
>>>>>>> an
>>>>>>> obsolete browser plugin) or SuperDevMode together with an embedded
>>>>>>> servlet
>>>>>>> container, by default Jetty. SuperDevMode is implemented in class
>>>>>>> com.google.gwt.dev.codeserver.CodeServer and DevMode basically calls
>>>>>>> this
>>>>>>> class if you request it to launch SuperDevMode (which is the default
>>>>>>> behavior). Class DevMode has a parameter "-noserver" which skips
>>>>>>> starting
>>>>>>> Jetty and assumes you have your own server and deployment running.
>>>>>>> Because
>>>>>>> we advocate running your own servlet container, e.g. Jetty/Tomcat/...,
>>>>>>> it
>>>>>>> is enough to just launch CodeServer yourself. However you could also
>>>>>>> continue to use class DevMode and replace the embedded Jetty with your
>>>>>>> own
>>>>>>> implementation using DevMode -server
>>>>>>> your.impl.of.ServletContainerLauncher.
>>>>>>> Your own implementation could then be based on Jetty 12 for example
>>>>>>> (and
>>>>>>> possibly jakarta)
>>>>>>>
>>>>>>> Personally I use Gradle and have a task that just launches
>>>>>>> CodeServer by executing a command line. I am pretty sure you could also
>>>>>>> write a similar ANT task using your current ANT setup. The command line
>>>>>>> looks like
>>>>>>>
>>>>>>> com.google.gwt.dev.codeserver.CodeServer -sourceLevel 11 -strict
>>>>>>> -failOnError - bindAddress 0.0.0.0 -port 9876 -style PRETTY
>>>>>>> -XmethodNameDisplayMode ABBREVIATED -workDir
>>>>>>> /client-project/build/gwt/work
>>>>>>> -launcherDir /client-project/build/gwt/war -src
>>>>>>> /shared-project/src/main/java -src /shared-project/src/main/resources
>>>>>>> com.example.MyGwtModule
>>>>>>>
>>>>>>> The classpath should contain gwt-user/gwt-dev/gwt-codeserver, all
>>>>>>> compile-time dependencies you need for GWT compilation as well as
>>>>>>> classes +
>>>>>>> sources + resources related to your GWT UI and DTOs. You would need to
>>>>>>> use
>>>>>>> ANT fileset/dirset/files to include/exclude only the files of your
>>>>>>> single
>>>>>>> project that are relevant for GWT compilation. Once you have that set
>>>>>>> of
>>>>>>> files figured out you can run GWT CodeServer in isolation via ANT with
>>>>>>> its
>>>>>>> own GWT focused classpath and you should not have any trouble with
>>>>>>> other
>>>>>>> dependencies that you need on the server only.
>>>>>>>
>>>>>>> Once you have that running, you need to decide how you want to run a
>>>>>>> servlet container. Personaly I use Docker + docker-compose + Jetty
>>>>>>> image +
>>>>>>> shell script.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>> 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 [email protected].
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/google-web-toolkit/e391c8f6-c957-481a-bd83-8f9cf1803353n%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/google-web-toolkit/e391c8f6-c957-481a-bd83-8f9cf1803353n%40googlegroups.com?utm_medium=email&utm_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 [email protected].
>>>
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/google-web-toolkit/279d54a8-834b-40c5-8f0e-3bc23ee54a7bn%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/google-web-toolkit/279d54a8-834b-40c5-8f0e-3bc23ee54a7bn%40googlegroups.com?utm_medium=email&utm_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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/67ab5e06-9eb1-4c05-a9eb-9a30e17a75e5n%40googlegroups.com.
