Hi Wejden, GXT does not have an open source licensing as far as I know. Not sure if you're legally allowed to modify & recompile the sources. That might be worth checking out before you put a lot of work into it.
rg, Leon. On Mon, Mar 31, 2025 at 12:20 PM Wejden Mrabti <[email protected]> wrote: > many thanks @Colin and @Jens > > I'm currently testing a *partial migration* of my GWT application to *Java > 11 and GWT 2.10*. To get a better idea of the work involved, I tried > compiling just one module of the project. > > Here’s what I’ve done so far: > > - > > Patched and recompiled gxt-2.3.1a to make it compatible with GWT 2.10 > ( > > https://groups.google.com/g/google-web-toolkit/c/If897MPqvw0/m/bSWnmuz9BwAJ?pli=1 > = > - > > Installed the modified JAR locally in my Maven repository > - > > Tried compiling a single module — but run into several issues > > Main issues I’m facing: > > - > > *Component (GXT) is no longer compatible with Widget (GWT)* ===> > breaks all UI layouts > - > > Many GXT-based custom components like > com.extjs.gxt.ui.client.widget.form.TextField, LabelField, etc. are *not > compatible anymore* > - > > *Stricter typing in Java 11 + GWT 2.10* ===> leads to many > generic/interface mismatches > - > > Several dependencies also need to be replaced or upgraded > > My question: > > Given that the application is *heavily dependent on GXT 2.3.1a*, > especially for the client-side (grids, forms, fields, etc.), *Is it worth > trying to patch and adapt GXT further?* > Or should I progressively migrate everything to *native GWT widgets* > (like Composite, DataGrid, etc.)? > > Has anyone gone through a similar migration? *Are all these issues common* > when trying to use a patched GXT with GWT 2.10? > > Any advice or shared experience would be super appreciated! > > Thanks a lot > wejden > > Le dimanche 23 mars 2025 à 20:26:32 UTC+1, Colin Alworth a écrit : > >> #1 I think Jens covers it well - something is almost certainly wrong with >> your modified jar or how the classpath is built. >> >> For #2, the "-server" argument lets you specify a >> com.google.gwt.core.ext.ServletContainerLauncher type, so >> org.eclipse.jetty.server.Server will not suffice. If you do not specify >> one, as of GWT 2.12 the old default of >> com.google.gwt.dev.shell.jetty.JettyLauncher (using a wrapped Jetty 9) is >> still used, which is what it sounds like you want anyway. This will change >> in the future, see https://github.com/gwtproject/gwt/issues/10057 and >> linked issues, If you're interested in something newer than the default >> Jetty 9, also see >> https://groups.google.com/g/google-web-toolkit/c/3dSoHpHD5jY/m/faAeQeJ-AwAJ >> and >> https://groups.google.com/g/google-web-toolkit-contributors/c/7jvGVaiSUdI >> . >> >> Note that Jetty 9 sometimes doesn't behave nicely when it tries to scan >> your classpath - if it finds something that it can't understand while >> looking for annotations, it will break. This will result in an error >> something like >> java.lang.IllegalArgumentException: Unsupported class file major version >> 64 >> at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199) >> at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180) >> at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166) >> at org.objectweb.asm.ClassReader.<init>(ClassReader.java:287) >> at >> org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932) >> at >> org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:734) >> ... 6 more >> >> The workaround discussed at >> https://github.com/gwtproject/gwt/issues/9433#issuecomment-250104877 may >> help here. >> >> #3, nothing special should be required - besides the wrong instance >> passed to -server, what errors are you seeing? >> >> Re your note: you should not need to deploy a complete war to tomcat for >> local development - the best way to think about this is "If I wasn't using >> GWT, how would I want to debug my server", then amend that slightly to >> permit SDM to change files in the same sort of way that you would either >> manually edit JS/HTML or you'd use a tool like npm/etc. >> >> On Sunday, March 23, 2025 at 3:23:07 AM UTC-5 [email protected] wrote: >> >>> Hello! >>> >>> I am following your conversation because i am working on same issues : >>> >>> >>> Migrating GWT/GXT project to GWT 2.10 + Java 11 + Jetty 9 >>> >>> *Initial Context on Legacy project using:* >>> >>> - >>> >>> GWT 2.8.2 >>> - >>> >>> GXT 2.3.1a-gwt22 >>> - >>> >>> Embedded Jetty >>> - >>> >>> Java 8 >>> >>> *Migration Goal* >>> >>> Update the project to use: >>> >>> - >>> >>> Java 11 >>> - >>> >>> GWT 2.10.1 >>> - >>> >>> Jetty 9 >>> - >>> >>> A custom-built GXT version compatible with GWT 2.10 >>> >>> *Steps Already Completed * >>> >>> 1. GXT Recompilation and Installation >>> >>> - >>> >>> Cloned the GXT 2.3.1a sources. >>> - >>> >>> Adapted the code to compile with GWT 2.10.1. >>> - >>> >>> Successfully built gxt-main-2.3.1a-gwt2.10.jar. >>> - >>> >>> Installed it locally using: >>> >>> >>> 2. Maven Configuration Updated >>> >>> - >>> >>> Switched to Java 11 using maven.compiler.source and target. >>> - >>> >>> GWT updated to version 2.10.1. >>> - >>> >>> Added the locally installed GXT dependency >>> >>> 3. GWT Module Inheritance Added >>> 4. GXT Verification >>> >>> - >>> >>> Confirmed GXT.gwt.xml is present inside the JAR (jar tf checked). >>> - >>> >>> JAR added to the Eclipse launch configuration (Run Configurations > >>> Classpath). >>> >>> Jetty Configuration Jetty 9 Already in Use >>> >>> - >>> >>> Version confirmed: 9.4.52.v20230823 (via mvn dependency:tree). >>> - >>> >>> Dependencies have <scope>compile</scope> (not provided). >>> - >>> >>> jetty-server-9.4.52.v20230823.jar appears in the Eclipse classpath. >>> >>> >>> *Current Blocking Issues* >>> >>> 1. GXT Not Found at Runtime >>> >>> When launching GWT DevMode: Unable to find >>> 'com/extjs/gxt/ui/GXT.gwt.xml' on your classpath >>> >>> Despite: >>> >>> - >>> >>> The file being present in the JAR. >>> - >>> >>> The JAR being listed in the Run Configurations > Classpath. >>> - >>> >>> Proper inheritance in the .gwt.xml file. >>> >>> 2. Jetty Server Class Not Found >>> >>> Tried using the argument: >>> >>> -server org.eclipse.jetty.server.Server >>> >>> *ClassNotFoundException: org.eclipse.jetty.server.*Server >>> >>> Even though the JAR is present in the classpath, and Jetty 9 is >>> confirmed to be in use. >>> >>> *So i need to understand* >>> >>> 1. >>> >>> Why is GWT DevMode (or CodeServer) unable to >>> find com.extjs.gxt.ui.GXT.gwt.xml, even though it is present and properly >>> declared? >>> 2. >>> >>> How can I resolve >>> the ClassNotFoundException for org.eclipse.jetty.server.Server, despite >>> Jetty 9 being correctly added? >>> 3. >>> >>> Are there any special configurations or recommendations for running >>> GWT 2.10 with Jetty 9 and Java 11 in Eclipse? >>> >>> *Important note:* I do *not* want to switch to a Tomcat 9 deployment >>> (war packaging) as a workaround. The current state of the project makes the >>> packaging and deployment process extremely slow — over *one hour* just >>> to build and deploy. Therefore, I need a solution that works using GWT >>> Super DevMode and embedded Jetty >>> >>> Thanks in advance for any help or suggestions. >>> >>> >>> __wejden >>> >>> >>> >>> Le mercredi 12 mars 2025 à 17:32:47 UTC+1, Jens a écrit : >>> >>> As Colin said you can use @WebServlet and enable configuration via >>> annotation scanning in your servlet container. However if your application >>> is large then scanning might slow your deployment down. If deployment time >>> is not a concern then it is the easiest solution. There are additional >>> annotations for other classes you normally add to your web.xml. >>> >>> If you don't like class scanning during deployment time you can write an >>> annotation processor that picks up all these @WebServlet annotated servlets >>> and generates a class that registers them using the ServletContext API. >>> Then you use that generated class in a custom ServletContextListener >>> implementation to register everything. That ServletContextListener would >>> then be the only entry in your web.xml. Alternatively, if you use Jetty as >>> servlet container you can use Jetty's quickstart module to let it generate >>> a web.xml by scanning your code once (as part of the build process). >>> >>> -- J. >>> >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "GWT Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/google-web-toolkit/db0a94c4-6dc7-45f3-b203-671e677b271en%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit/db0a94c4-6dc7-45f3-b203-671e677b271en%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/CABjQu7THuwTiY3ZHV-Em3atB4dZGNBO-APA9rxyxCP7hPkvm6A%40mail.gmail.com.
