Yes SuperDev can work without Jetty (well, without at least explicitly
using it), you don't need it at all.
The web app should be developed and debugged in real environment, and
Eclipse WTP platform allows for just that, selecting your brand of the
webapp server. No need for an inaccurate substitute.
SuperDev can and should be launched as separate application then there will
be no JAR mess. Then your web app will not be aware of the SuperDev app at
all, about its classpath, web server it uses, etc.
A browser will load the javascript code generated by the SuperDev from your
java sources on the fly, from the SuperDev running as a standalone web app
(Jetty or whatever, used to deliver the transpiled code to browser).
The Javascript code (compiled from your java sources) will communicate to
your own server (configured in Eclipse) through GWT calls.
On Tuesday, March 18, 2025 at 3:54:59 AM UTC+1 Dyllan Sowers wrote:
> 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/647cce7d-cfc5-4702-a53f-29fa4f1f1770n%40googlegroups.com.
