Monday, March 31, 2025

Re: Suggestion on upgrading gwt-2.6.1 to latest

From publicly available sources, I can only confirm three compile errors in GXT 2.3.1a-gwt22 (the final release of GXT 2, compatible at the time with the latest GWT version) when compiling with GWT 2.12.2. I also verified with GWT 2.10.1, gxt itself has no other compile errors. Those errors are in TreePanel, ListView, and ListField, and all three can be fixed with a cast (as above, it appears that redistributing the modifications is against the license terms, but I feel confident in saying just that a cast fixes each). It is possible that building with your entire application changes things in some way, but I am compiling with -failOnErrors which _should_ outright fail if any class isn't entirely valid for use in GWT.

GXT 2 has no external third-party dependencies.

I cannot confirm that GXT's Component is no longer compatible with GWT 2.10+'s Widget type.

It seems likely that remaining issues are part of your application, rather than GXT 2 (or GWT)?

On Monday, March 31, 2025 at 7:13:48 AM UTC-5 wejden...@gmail.com wrote:
thanks @colin @leon

Aside from the licensing concerns, I'm mostly interested in the technical and conceptual side of things.

From a conceptual standpoint — for those who have attempted similar upgrades —
Have you encountered the same main issues I've listed below when trying to run GXT 2.3.1a with GWT 2.10?

Main issues I'm seeing:

  • Component (GXT) is no longer compatible with Widget (GWT), breaking most UI layout logic

  • Many core GXT components like TextField, LabelField, FormPanel, etc. are no longer usable

  • GWT 2.10 + Java 11 enforces stricter type checks → tons of generic mismatches and interface conflicts

  • Several third-party dependencies are broken or require updates 

I'd love to know if others faced similar roadblocks or found any strategies to make GXT 2.x work (even partially) with GWT 2.10 — or if full migration to GWT-native components was the only way forward ;)

Thanks again for any insight!


wejden



Le lun. 31 mars 2025 à 13:59, Colin Alworth <co...@colinalworth.com> a écrit :
Their license is pretty clear on this matter:

> We provide You with source code to the Sencha SDKs so that You can create Modifications and Applications. While You retain all rights to any original work authored by You as part of the Modifications, We continue to own all copyright and other intellectual property rights in the Sencha SDKs.

It does however go on to say that you cannot share the modified sdk though (nor the patches themselves):

> You may not redistribute the Sencha SDKs or Modifications other than by including the Sencha SDKs or a portion thereof within Your Application.


I am not a lawyer, I am not your lawyer, etc. 


On Mon, Mar 31, 2025, at 6:43 AM, Leon wrote:
Hi Wejden, I would still recommend to check on whether or not that includes the right to modify and/or recompile the sources.

On Mon, Mar 31, 2025 at 1:40 PM Wejden Mrabti <wejden...@gmail.com> wrote:
@leon we already have commercial licence 


Best Regards,
Wejden MRABTI

Ingénieur étude et développement


Le lun. 31 mars 2025 à 12:46, Leon <leon.p...@gmail.com> a écrit :
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 <wejden...@gmail.com> 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:

 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


#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 wejden...@gmail.com 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 group and all its topics, send an email to google-web-tool...@googlegroups.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.


--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.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.

--
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.


--
Best Regards,
Wejden MRABTI

Ingénieur étude et développement

--
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/56edc394-c92f-4cf8-aab4-08b7caf3137dn%40googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)