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/f7ed3910-16ef-4d98-8840-61da6dce105dn%40googlegroups.com.
