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}"
"${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()
}
}
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 google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/e391c8f6-c957-481a-bd83-8f9cf1803353n%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-tool...@googlegroups.com.To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/279d54a8-834b-40c5-8f0e-3bc23ee54a7bn%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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/f7ed3910-16ef-4d98-8840-61da6dce105dn%40googlegroups.com.
No comments:
Post a Comment