Tuesday, May 24, 2022

Re: Is there an easy way to use GWT Request Factory?

I'm using GWT-RPC, and it works great!

I have a version number (that is used by the client and server) that I update when I make a breaking RPC change.  If the client detects it has a different version number to the server, it shows the user a message that they need to refresh their browser, as a new version has been released.

Probably not the optimum solution, but it works fine for my needs.

On Wednesday, 25 May 2022 at 8:15:50 am UTC+10 hprc wrote:
thank you for the advice
I have a poor understanding of Maven, so I can only add functionality in the basic way.

I know myself
1 Build and run using Eclipse and GWT plugin
2 Add jar to build path
3 Add by adding <inherits> tag

If you prefer, it would be helpful if you could download the jars you need for domino-rest.

2022年5月24日火曜日 22:16:47 UTC+9 frank.h...@googlemail.com:

You can use domino-rest without using maven. But Maven will make things much easier.

There are several examples demontrating the use of the Domino-Stack (including domino-rest) Also, in most cases, it does not depend on Eclipse. F.e.: check: https://github.com/NaluKit/nalu-examples/tree/main/nalu-complex-app-example. This example demonstrate how to do things in Nalu. This example uses domino-rest for the communication. (I am pretty sure Ahmad & Rafat have similar examples using the domino stack). Just follow the instructions inside the readme.txt. All you need to do is to install Java and Maven and make it available from your terminal. 


hprc schrieb am Dienstag, 24. Mai 2022 um 02:15:12 UTC+2:
Re [domino-rest]
It's a great API, you can use POJO and REST respectively.
However, I don't know how to use ECLIPSE + GWT + MOVEN, so it's sad that I can't use it right away.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/782f571c-7389-4eff-9804-95dbd1c419fen%40googlegroups.com.

Tuesday, March 22, 2022

Re: Micro-Frontends Session with GWT example

Here are the slides... enjoy 😉 

https://bit.ly/MicrofrontendsNavigate2022

lofid...@gmail.com schrieb am Samstag, 19. März 2022 um 11:40:33 UTC+1:
Hi All,

Friendly reminder: next week I have a session for Micro-Frontends. Free, online, language German but the slides are in English 😉 I'll show a short demo in GWT: https://navigate-kongress.de/class/web-micro-frontends/

Here is the example: https://github.com/gwtboot/microfrontends-example

Enjoy, Lofi

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/46423608-f45e-4e65-ba20-4e1c9e4421dbn%40googlegroups.com.

Tuesday, March 15, 2022

Re: hilla.dev

Guilty, I was being a little over simplistic.  :)

Sometimes I love Springboot, Spring Security, etc, and other times I hate it.  So I can understand your view there.

I guess I saw the Vaadin web components, Lit framework, Spring, etc, all things that you can get standalone.  However, I guess Hilla are packaging them up for you to work nicely together, so probably should be considered part of it.

On Monday, 14 March 2022 at 9:40:45 pm UTC+11 t.br...@gmail.com wrote:
I haven't tried it (if only because of Spring) but your description is overly reductive IMO.
Hilla is made of (at least) 3 parts:
  • client-side library of web components (router, form data-binding, data grids, etc.)
  • server-side framework (or only scaffolding?) based on Spring Boot, à la JHipster
  • code generator that takes Java code for your Spring Boot endpoints and generates TypeScript code to call them, and type definitions for direct use with the form data-binding components (the generator actually is itself made of 2 parts: generates an OpenAPI spec from the Spring Boot endpoints, then generates TypeScript from that OpenAPI spec; it doesn't support all of OpenAPI though, as it's tailored for the Hilla backend, wrt authentication for instance).

On Monday, March 14, 2022 at 6:07:53 AM UTC+1 Craig Mitchell wrote:
Has anyone tried https://hilla.dev/ ?  It seems like GWT minus most of the bits.  Ie: They give you the model in TypeScript, then it's up to you to do the rest.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c11be2d6-b39b-4ef3-b9e2-b4cdc4163714n%40googlegroups.com.

Monday, February 21, 2022

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

Sounds interesting, I'll definitely give it a try, thank you - and for the gradle file, I really need a production grade gradle example 

понедельник, 21 февраля 2022 г. в 11:27:04 UTC+1, Luis Fernando Planella Gonzalez:
> Our current workflow is using SuperDevMode + Jetty and I'd like to provide similar experience to our team.
I had a similar concern, as before we both SuperDevMode and the app in the same Java process.
After the switch, we need to start the codeserver and then the app, via Tomcat. But, things went well, because:
  1. You don't have to start your app in the build tool and connect remotely. The codeserver will write its files to the same place as the regular compilation would, and you can start your app in a debug session in Eclipse. We're using the built-in Tomcat server (with Eclipse WTP). Just make sure that after starting the codeserver, you have your workspace refreshed, so Eclipse can publish it accordingly (that's why we wrote the script, as mentioned in the previous post)
  2. Starting the codeserver is actually slower than the app (at least for us, and the app is huge). When you debug the app, you'll eventually do an incompatible change that needs to restart the app. When using the codeserver as a separated process, it stays there, in the same place, even when you restart the app. IMO, this ended up being more productive than the previous setup
  3. If GWT 3 is ever released, having a separated codeserver will be the only option

Em domingo, 20 de fevereiro de 2022 às 20:55:55 UTC-3, tequil...@gmail.com escreveu:
Thanks for the answer

> Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Do you mean disabling java.xml module of JRE and depend on all xml stuff explicitly? It means I'd have to rely on dependencies instead of stock libraries (general app architecture choice) just to comply with a flawed development tool needed only to run debug sessions. I'd prefer to avoid it unless it's the only way.

>  Alternatively, how about not using the Eclipse GWT Plugin?

Our current workflow is using SuperDevMode + Jetty and I'd like to provide similar experience to our team. 
I saw such solutions (using gradle gretty plugin), so far decided against it. As far as I understand running the code server and my webapp via Gradle without Eclipse GWT plugin brings more hassle into everyday development routine. This way the webapp must be launched not as Eclipse debugging session but as Gradle task, and connected via remote debugging session. I'd like to avoid it.

воскресенье, 20 февраля 2022 г. в 12:33:18 UTC+1, t.br...@gmail.com:
On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:
Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Alternatively, how about not using the Eclipse GWT Plugin?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/591d9dee-286d-4b9e-9d95-e28a5d607be1n%40googlegroups.com.

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

> Our current workflow is using SuperDevMode + Jetty and I'd like to provide similar experience to our team.
I had a similar concern, as before we both SuperDevMode and the app in the same Java process.
After the switch, we need to start the codeserver and then the app, via Tomcat. But, things went well, because:
  1. You don't have to start your app in the build tool and connect remotely. The codeserver will write its files to the same place as the regular compilation would, and you can start your app in a debug session in Eclipse. We're using the built-in Tomcat server (with Eclipse WTP). Just make sure that after starting the codeserver, you have your workspace refreshed, so Eclipse can publish it accordingly (that's why we wrote the script, as mentioned in the previous post)
  2. Starting the codeserver is actually slower than the app (at least for us, and the app is huge). When you debug the app, you'll eventually do an incompatible change that needs to restart the app. When using the codeserver as a separated process, it stays there, in the same place, even when you restart the app. IMO, this ended up being more productive than the previous setup
  3. If GWT 3 is ever released, having a separated codeserver will be the only option

Em domingo, 20 de fevereiro de 2022 às 20:55:55 UTC-3, tequil...@gmail.com escreveu:
Thanks for the answer

> Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Do you mean disabling java.xml module of JRE and depend on all xml stuff explicitly? It means I'd have to rely on dependencies instead of stock libraries (general app architecture choice) just to comply with a flawed development tool needed only to run debug sessions. I'd prefer to avoid it unless it's the only way.

>  Alternatively, how about not using the Eclipse GWT Plugin?

Our current workflow is using SuperDevMode + Jetty and I'd like to provide similar experience to our team. 
I saw such solutions (using gradle gretty plugin), so far decided against it. As far as I understand running the code server and my webapp via Gradle without Eclipse GWT plugin brings more hassle into everyday development routine. This way the webapp must be launched not as Eclipse debugging session but as Gradle task, and connected via remote debugging session. I'd like to avoid it.

воскресенье, 20 февраля 2022 г. в 12:33:18 UTC+1, t.br...@gmail.com:
On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:
Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Alternatively, how about not using the Eclipse GWT Plugin?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b90a7c37-81ad-4768-ad97-e6a830e9a670n%40googlegroups.com.

Sunday, February 20, 2022

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

Thanks for the answer

> Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Do you mean disabling java.xml module of JRE and depend on all xml stuff explicitly? It means I'd have to rely on dependencies instead of stock libraries (general app architecture choice) just to comply with a flawed development tool needed only to run debug sessions. I'd prefer to avoid it unless it's the only way.

>  Alternatively, how about not using the Eclipse GWT Plugin?

Our current workflow is using SuperDevMode + Jetty and I'd like to provide similar experience to our team. 
I saw such solutions (using gradle gretty plugin), so far decided against it. As far as I understand running the code server and my webapp via Gradle without Eclipse GWT plugin brings more hassle into everyday development routine. This way the webapp must be launched not as Eclipse debugging session but as Gradle task, and connected via remote debugging session. I'd like to avoid it.

воскресенье, 20 февраля 2022 г. в 12:33:18 UTC+1, t.br...@gmail.com:
On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:
Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Alternatively, how about not using the Eclipse GWT Plugin?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/d7d7069d-0e20-49e1-95f1-6e9153b03ccbn%40googlegroups.com.

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

description = 'GWT client'

ext {
buildWebapp = "${project(':projectname-web').buildDir}/generated/webapp"
gwtDev = Boolean.getBoolean('gwt.development')
}

sourceSets {
main {
java {
srcDir rpcSrc
srcDir exceptionsSrc
}
}
}

configurations {
gwt
}
dependencies {
api project(':projectname-api')
implementation "com.google.gwt:gwt-user:$gwtVersion"
implementation("com.github.branflake2267:gwt-maps-api:$googleMapsApiVersion") {
transitive = false
}
implementation "com.google.elemental2:elemental2-webstorage:$elementalVersion"
implementation "com.google.elemental2:elemental2-dom:$elementalVersion"
implementation "com.google.elemental2:elemental2-promise:$elementalVersion"

gwt(project(':projectname-api')) { transitive = false }
gwt files(project.sourceSets.main.java.srcDirs)
gwt files(project.sourceSets.main.resources.srcDirs)
gwt files(project(':projectname-common').sourceSets.main.java.srcDirs)
gwt files(project(':projectname-api').sourceSets.main.java.srcDirs)
gwt files(project(':projectname-api-core').sourceSets.main.java.srcDirs)
gwt "com.google.gwt:gwt-user:$gwtVersion"
gwt "com.google.code.gwtx:gwtx:$gwtxVersion"
gwt "com.github.branflake2267:gwt-maps-api:$googleMapsApiVersion"
gwt "com.google.elemental2:elemental2-webstorage:$elementalVersion"
gwt "com.google.elemental2:elemental2-dom:$elementalVersion"
gwt "com.google.elemental2:elemental2-promise:$elementalVersion"
gwt "com.fasterxml.jackson.core:jackson-annotations:$jacksonVersion"
gwt "com.google.gwt:gwt-dev:$gwtVersion"
}

task compileGwt(type: JavaExec) {
dependsOn compileJava
ext {
outDir = "$buildWebapp/projectname.gwt"
}
group = 'Build'
description = 'Compile the GWT source'
inputs.files configurations.gwt
inputs.property 'development', gwtDev
outputs.dir outDir
classpath = configurations.gwt
mainClass = 'com.google.gwt.dev.Compiler'
args = []
args += ['-sourceLevel', "1.${project.parent.ext.javaVersion}"]
args += ['-war', buildWebapp]
args += ['-logLevel', 'INFO']
args += ['-workDir', "$buildDir/tmp/gwt"]
args += ['-XfragmentCount', '6']
args += ['-failOnError']
if (gwtDev) {
args += ['-style', 'PRETTY']
args += ['-draftCompile']
args += ['-optimize', '0']
args += ['-XmethodNameDisplayMode', 'ABBREVIATED']
args += ['org.projectname.ProjectNameDev']
} else {
args += ['-style', 'OBFUSCATED']
args += ['-optimize', '9']
args += ['-XnoclassMetadata']
args += ['org.projectname.ProjectName']
}
}
task cleanGwtTemp {
doLast {
ant.delete(dir: "$buildWebapp/projectname.gwt")
ant.delete(dir: "$buildDir/tmp/gwt")
}
}
cleanCompileGwt {
dependsOn cleanGwtTemp
}
clean {
dependsOn cleanGwtTemp
}

task gwtSuperDev(type: JavaExec) {
dependsOn compileJava
description = 'Run the GWT code server for Super Dev Mode'
classpath = configurations.gwt
mainClass = 'com.google.gwt.dev.codeserver.CodeServer'
args = []
args += ['-sourceLevel', "1.${project.parent.ext.javaVersion}"]
args += ['-launcherDir', buildWebapp]
args += ['-logLevel', 'INFO']
args += ['-workDir', "$buildDir/tmp/gwt"]
args += ['-precompile']
args += ['-failOnError']
args += ['-bindAddress', '0.0.0.0']
args += ['org.projectname.ProjectNameDev']

doFirst {
file("$buildDir/tmp/gwt").mkdirs()
}
}
We started using GWT in our project in 2009 (GWT 1.5.0!)
When we moved from Maven to Gradle in 2020 (one of the best decisions ever, because the project is complex, has a lot of code generation and Gradle's skipping of already executed tasks is a must - it was unbearable with Maven), we've also dropped the GWT Eclipse plugin altogether.
Also, we don't use a GWT plugin for Gradle either: instead, we just run either GWT codeserver or compiler via their main classes, setting up the classpath correctly.
To start with, as we already had multiple modules in the build system (api / impl / web, etc), we've split the GWT classes to a new module (no longer the web project).

Attached in this post is the anonymized and stripped down build.gradle file for the gwt module.

Finally, for us to be productive again in Eclipse, we've written a script that does the following:
  1. Delete the destination's nocache.js file
  2. Starts the code server via gradle, redirecting the output to a file
  3. Sleeps until the nocache.js file exists again
  4. Write the PID of the gradle process to a file
We run this from an Eclipse external tool, and have the tool's refresh option to refresh the web's project output dir. This way the publishing works flawlessly in Eclipse with a Tomcat server.

We've also created other 2 similar scripts / Eclipse tools: one to stop the codeserver (kill the process with the PID indicated in the file) and another one to show the codeserver log (tail -f1000 -n in the output file).

We'll never look back to neither the Eclipse plugin (which did many other things we don't use) nor to a Gradle plugin (which were mostly written once and abandoned, and Gradle evolves fast, introducing breaking changes, and that broke the project more than once).

Em domingo, 20 de fevereiro de 2022 às 08:33:18 UTC-3, t.br...@gmail.com escreveu:
On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:
Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?

Alternatively, how about not using the Eclipse GWT Plugin?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5974a25e-6e59-435c-b7af-05d1b4e038f2n%40googlegroups.com.

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.



On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com wrote:
Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Can't you somehow disable the module path or put all dependencies in the classpath rather than the module path?
https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-properties-build-path.htm&resultof%3D%2522%256a%2570%256d%2573%2522%2520%2522%256a%2570%256d%2522%2520 

Alternatively, how about not using the Eclipse GWT Plugin?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/de8dff95-a151-4d79-b416-2f8a3e3bf947n%40googlegroups.com.

Friday, February 18, 2022

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

Hi Jasper

I'll be just glad if my current progress saves someone's time.
I progress on step by step basis, so far I succeeded in Eclipse build and debugging.

Most of my problems were caused by combination of JDK11+ (namely modules) + Gradle + Eclipse + Eclipse GWT Plugin. 

Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be visible to Eclipse compiler, but in fact they are, causing dreaded "The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml" error.
When `gradle build` is issued in command line the gwt-dev.jar from the maven repository is linked, it contains exactly essential google classes and nothing more. Thus the build succeeds.

But when you import such project in Eclipse under JDK11+ (I use JDK17) and select a GWT SDK there're lots of build errors caused by "The package is accessible from more than one module"

Reason: To run devmode or compilation server in Eclipse via Eclipse GWT plugin, you need full-blown gwt-dev.jar, so you need to install a GWT SDK and select it in your Eclipse project. And for some reason (by design of the Eclipse GWT plugin) this gwt-dev.jar from SDK spoils the Eclipse compilation classpath even if the build.gradle adds a dependency to the "essential" gwt-dev.jar

Indeed the Eclipse GWT Plugin allows to use an "essential" gwt-dev.jar from project dependencies instead of a real GWT SDK (even without installing it and registering in Eclipse), but only for Maven projects. Gradle is not covered. 

My solution was to patch an existing GWT SDK:

1. prepare GWT SDK 
assuming we have it installed into gwt-2.9.0 folder:
  mv gwt-2.9.0 gwt-2.9.0-jdk11
  cd gwt-2.9.0-jdk11

rename full blown gwt-dev 
  mv gwt-dev.jar gwt-dev-rundevserver-full.jar

 then assuming we already have dependencies stored in cache let's get the "essential" jar 
  cp ~/.m2/repository/com/google/gwt/gwt-dev/2.9.0/gwt-dev-2.9.0.jar gwt-dev.jar
 it will leak to Eclipse build classpath but it's jdk11-conformant (or rather Jigsaw conformant)

2. add the patched GWT SDK (its folder name gwt-2.9.0-jdk11 is used as its name) to Eclipse project via maven, so it will be already bound after project import
  
  eclipse.classpath {
    containers "com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER/gwt-2.9.0-jdk11"
  }

3. Fix compilation server launcher

Let's refer the full-blown jar in launcher started by GWT Plugin:

Add a web server to eclipse (Tomcat or another one), 
add your webapp to the server (at this moment I usually set server start timeout to really long interval and uncheck the webapp "autoreloading enabled" to avoid webapp relaunch on hot code replace), 
then click "debug server" button:
  -> compilation server launcher config will be created, your webapp and the compilation server will launch but the latter will fail because the gwt-2.9.0-jdk11/gwt-dev.jar only contains skeleton files 
 
Stop the webapp
Edit the compilation server configuration: 
Edit classpath adding GWT_SDK_HOME/gwt-dev-rundevserver-full.jar as external jar to the [User entries] as the last entry:

image_2022-02-19_013438.png
 
"Debug server" once more: the compilation server must start and work now. The debugger and hot code replace for server classes will work as they should, and the changes to client java GWT files will be promptly recompiled when you refresh the page. It works in web server of your choice, not in Jetty bundled with GWT SDK. 
And click-through / debugging into XML/Servlet classes no more opens java bytecode in fullblown gwt-dev.jar but proper source files of JDK or your dependencies.

Hope this helps

Tequilacat

среда, 16 февраля 2022 г. в 06:12:23 UTC+1, blackh...@gmail.com:
Hi ,

You mention that you are migrating from jdk 1.8 to jdk 17.
We are in the same process, any tips you have?

regards,

Jasper

Op dinsdag 15 februari 2022 om 22:30:30 UTC+1 schreef tequil...@gmail.com:
Hi, 

> You're all set; the plugin will use the GWT dependencies from the Maven project.

The question - can I configure it with gradle?

I'm porting a GWT gradle-based Eclipse project from JDK 1.8 to JDK 17 (and from 2.8.2 to 2.9.0)
In Eclipse, there's typical JDK11+ error "The package org.xml.sax.helpers is accessible from more than one module" and it looks like the org.xml.sax classes shipped in gwt-dev.jar clash with jdk. Eclipse compiler somehow refers gwt-dev.jar. 
Command line gradle build succeeds OK.
If maven-central version of gwt-dev doesn't contain duplicating classes it would save the day. 

Is there a way to configure gradle project to force Eclipse plugin to use GWT version from gradle dependencies?

I have GWT 2.9.0 installed and added in Eclipse. To avoid referring this all-inclusive gwt-dev I removed GWT-2.9.0 from list of GWT SDKs in Eclipse settings, and now after importing/refreshing my gradle project the GWT plugin SDK selection doesn't contain 2.9.0 anymore even if I specify gradle dependency.

thank you

среда, 24 июля 2019 г. в 17:40:21 UTC+2, t.br...@gmail.com:


On Wednesday, July 24, 2019 at 5:14:42 PM UTC+2, Jim Douglas wrote:
> Sure. Use a build tool of your choice and use the maven dependencies. 

I don't know what that means. As far as I've ever known, developing a GWT application in Eclipse implies installing the GWT Plugin for Eclipse and picking a GWT SDK.


Nope.
Install the GWT Eclipse Plugin (https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/Download.html; note that the SDKs are optional).
You're all set; the plugin will use the GWT dependencies from the Maven project.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b53b7396-a543-4549-a9e0-265a72434317n%40googlegroups.com.

Tuesday, February 15, 2022

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

Hi ,

You mention that you are migrating from jdk 1.8 to jdk 17.
We are in the same process, any tips you have?

regards,

Jasper

Op dinsdag 15 februari 2022 om 22:30:30 UTC+1 schreef tequil...@gmail.com:
Hi, 

> You're all set; the plugin will use the GWT dependencies from the Maven project.

The question - can I configure it with gradle?

I'm porting a GWT gradle-based Eclipse project from JDK 1.8 to JDK 17 (and from 2.8.2 to 2.9.0)
In Eclipse, there's typical JDK11+ error "The package org.xml.sax.helpers is accessible from more than one module" and it looks like the org.xml.sax classes shipped in gwt-dev.jar clash with jdk. Eclipse compiler somehow refers gwt-dev.jar. 
Command line gradle build succeeds OK.
If maven-central version of gwt-dev doesn't contain duplicating classes it would save the day. 

Is there a way to configure gradle project to force Eclipse plugin to use GWT version from gradle dependencies?

I have GWT 2.9.0 installed and added in Eclipse. To avoid referring this all-inclusive gwt-dev I removed GWT-2.9.0 from list of GWT SDKs in Eclipse settings, and now after importing/refreshing my gradle project the GWT plugin SDK selection doesn't contain 2.9.0 anymore even if I specify gradle dependency.

thank you

среда, 24 июля 2019 г. в 17:40:21 UTC+2, t.br...@gmail.com:


On Wednesday, July 24, 2019 at 5:14:42 PM UTC+2, Jim Douglas wrote:
> Sure. Use a build tool of your choice and use the maven dependencies. 

I don't know what that means. As far as I've ever known, developing a GWT application in Eclipse implies installing the GWT Plugin for Eclipse and picking a GWT SDK.


Nope.
Install the GWT Eclipse Plugin (https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/Download.html; note that the SDKs are optional).
You're all set; the plugin will use the GWT dependencies from the Maven project.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5093fb0f-be01-4172-b11f-f9612ebb0896n%40googlegroups.com.

Sunday, February 13, 2022

Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

Hi, 

> You're all set; the plugin will use the GWT dependencies from the Maven project.

The question - can I configure it with gradle?

I'm porting a GWT gradle-based Eclipse project from JDK 1.8 to JDK 17 (and from 2.8.2 to 2.9.0)
In Eclipse, there's typical JDK11+ error "The package org.xml.sax.helpers is accessible from more than one module" and it looks like the org.xml.sax classes shipped in gwt-dev.jar clash with jdk. Eclipse compiler somehow refers gwt-dev.jar. 
Command line gradle build succeeds OK.
If maven-central version of gwt-dev doesn't contain duplicating classes it would save the day. 

Is there a way to configure gradle project to force Eclipse plugin to use GWT version from gradle dependencies?

I have GWT 2.9.0 installed and added in Eclipse. To avoid referring this all-inclusive gwt-dev I removed GWT-2.9.0 from list of GWT SDKs in Eclipse settings, and now after importing/refreshing my gradle project the GWT plugin SDK selection doesn't contain 2.9.0 anymore even if I specify gradle dependency.

thank you

среда, 24 июля 2019 г. в 17:40:21 UTC+2, t.br...@gmail.com:


On Wednesday, July 24, 2019 at 5:14:42 PM UTC+2, Jim Douglas wrote:
> Sure. Use a build tool of your choice and use the maven dependencies. 

I don't know what that means. As far as I've ever known, developing a GWT application in Eclipse implies installing the GWT Plugin for Eclipse and picking a GWT SDK.


Nope.
Install the GWT Eclipse Plugin (https://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/Download.html; note that the SDKs are optional).
You're all set; the plugin will use the GWT dependencies from the Maven project.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/3c3c529b-7334-4a22-8fce-e9f73d323e43n%40googlegroups.com.

Tuesday, January 18, 2022

Re: Performance Comparison GWT Transpiler with MacBook Pro M1 Pro processor

I agree with you.


DeclanLawton | Consultant
Moweb Technologies Pvt. Ltd.

On Saturday, January 15, 2022 at 5:49:48 PM UTC+5:30 leon.p...@gmail.com wrote:
For around a 1000 euro, you can build a desktop that is faster compiling than any laptop.
And on linux the memory is used a lot more efficient than on a mac, so you need less.
That being said - I have a macbook when I travel. But in the office and at home I switched to working on desktops about 5 yrs ago.



Op woensdag 12 januari 2022 om 09:12:42 UTC+1 schreef Shawn:
I kinda like the Max 64GB.  I'm pushing 54GB used for eclipse (running an appengine dev and GWT server) during a build.  My upload to google cloud is slow so after the build I can easily start developing again while it's deploying.

I also use a ramdisk and set the GWT SuperDev mode to use that with  -workDir /Users/me/.tmpdisk/GWT_RAM_DISK.  Then build with an ant task and add this to the gwtc java task for building.

<sysproperty key="gwt.persistentunitcachedir" value="/Users/me/.tmpdisk/GWT_RAM_DISK"/>


No benchmarks but probably the biggest benefit is debugging which I still do in Eclipse via SDGB.

I haven't been able to get Eclipse to run natively as macOS AArch64 is only available from the 2021-12 version which just borks my project.  It seems to be a conflict with the google-cloud-plugin I use for appengine.  Still 2021-09 with emulated Eclipse is a major improvement especially since the dev server and build processes can be run natively.

Anyway, 32GB on a pro ordered today is about a month to get delivery and 64GB on a max is about two months.  I got a 64GB max with 32 GPUs (maybe I can use those for machine learning) as it was the only way to get more than 16GB of memory without waiting so long and I had to move suddenly and couldn't bring my iMac.  

On Tue, Jan 11, 2022 at 9:17 AM 'Frank Hossfeld' via GWT Users <google-we...@googlegroups.com> wrote:
No, sorry ... closed source. Yep, I agree with. Don't think, that the graphics CPUs will have an impact of the compile time.
So, the M1 Pro is a great choice for developers. Now I am waiting for the next Mac Pro ...

Jens schrieb am Montag, 6. Dezember 2021 um 10:32:15 UTC+1:
I did some tests with one of my larger GWT projects. It takes 3:55 on my "old" MacBook Pro 16" i9 2.4 GHz, 64 GB RAM. Same project build on a new MacBook Pro M1 Max 64 GB takes roundabout 2:00. That's an incredible improvement. 

Is that project public? Then I would try it with my M1 Pro 32gb which is IMHO the best value for developers, unless you do graphics stuff.

-- J. 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1702ce0b-23b9-4935-ab9c-ca36696442efn%40googlegroups.com.

Sunday, January 16, 2022

Re: Performance Comparison GWT Transpiler with MacBook Pro M1 Pro processor

Hi All,

thanks a lot for the data, really appreciate this 🙏

Apple M1 Max 64: 1m11s (identical with the test in my second article M1 Max)

and Linux AMD (which is much cheaper 😊): 1m33s 
... almost identical with M1 Pro: 1m25s (my first article)

So, for desktop we could just use Linux AMD, cheaper and fast enough 😅

Thanks a lot!
Lofi

leon.p...@gmail.com schrieb am Sonntag, 16. Januar 2022 um 10:17:36 UTC+1:

My current machine has an AMD Ryzen 5 5600X, 32GB mem - this was around a 900-1000 euro build from late last year.
I installed the same jdk and used the same mvn (see screenshots)

For normal mvn clean install I had 02:24 and for the mvn -T 1C clean install I had 1:33

I think for another 2-300 euro's for a better processor I could do a lot better still.

Leon.









Op zondag 16 januari 2022 om 02:46:22 UTC+1 schreef Shawn:
Hi,

01:11 min was the best I could get with an Apple M1 Max, 64GB.  

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary for gwt-boot-samples 1.0.0-SNAPSHOT:

[INFO] 

[INFO] gwt-boot-sample-basic .............................. SUCCESS [ 46.823 s]

[INFO] gwt-boot-sample-collection ......................... SUCCESS [01:07 min]

[INFO] gwt-boot-sample-elemento-core ...................... SUCCESS [ 53.763 s]

[INFO] gwt-boot-sample-elemento-template .................. SUCCESS [ 53.487 s]

[INFO] gwt-boot-sample-rxgwt .............................. SUCCESS [01:00 min]

[INFO] gwt-boot-sample-domino-rest ........................ SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-gwtbootstrap3 ................... SUCCESS [01:03 min]

[INFO] gwt-boot-sample-ui-gwtmaterial ..................... SUCCESS [01:08 min]

[INFO] gwt-boot-sample-ui-domino .......................... SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-domino-dagger2 .................. SUCCESS [01:10 min]

[INFO] gwt-boot-sample-ui-vue-gwt ......................... SUCCESS [01:00 min]

[INFO] gwt-boot-sample-ui-dncomponents .................... SUCCESS [01:07 min]

[INFO] gwt-boot-samples ................................... SUCCESS [  0.181 s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time:  01:11 min (Wall Clock)

[INFO] Finished at: 2022-01-15T12:39:42-10:00

[INFO] ------------------------------------------------------------------------

Shawn
On Saturday, January 15, 2022 at 5:38:21 AM UTC-10 lofid...@gmail.com wrote:
@leon.p:

This would be interesting...  Could you try to build the project as I mentioned in my article? To see what time we would get there?

Here is the article: 


and


Record is: 

1. Without -T 1C clean install: 2m21s
2. With -T 1C clean install: 1m13s

Would like to see if someone can get faster than this 😉

Thanks, Lofi
leon.p...@gmail.com schrieb am Samstag, 15. Januar 2022 um 13:19:48 UTC+1:
For around a 1000 euro, you can build a desktop that is faster compiling than any laptop.
And on linux the memory is used a lot more efficient than on a mac, so you need less.
That being said - I have a macbook when I travel. But in the office and at home I switched to working on desktops about 5 yrs ago.



Op woensdag 12 januari 2022 om 09:12:42 UTC+1 schreef Shawn:
I kinda like the Max 64GB.  I'm pushing 54GB used for eclipse (running an appengine dev and GWT server) during a build.  My upload to google cloud is slow so after the build I can easily start developing again while it's deploying.

I also use a ramdisk and set the GWT SuperDev mode to use that with  -workDir /Users/me/.tmpdisk/GWT_RAM_DISK.  Then build with an ant task and add this to the gwtc java task for building.

<sysproperty key="gwt.persistentunitcachedir" value="/Users/me/.tmpdisk/GWT_RAM_DISK"/>


No benchmarks but probably the biggest benefit is debugging which I still do in Eclipse via SDGB.

I haven't been able to get Eclipse to run natively as macOS AArch64 is only available from the 2021-12 version which just borks my project.  It seems to be a conflict with the google-cloud-plugin I use for appengine.  Still 2021-09 with emulated Eclipse is a major improvement especially since the dev server and build processes can be run natively.

Anyway, 32GB on a pro ordered today is about a month to get delivery and 64GB on a max is about two months.  I got a 64GB max with 32 GPUs (maybe I can use those for machine learning) as it was the only way to get more than 16GB of memory without waiting so long and I had to move suddenly and couldn't bring my iMac.  

On Tue, Jan 11, 2022 at 9:17 AM 'Frank Hossfeld' via GWT Users <google-we...@googlegroups.com> wrote:
No, sorry ... closed source. Yep, I agree with. Don't think, that the graphics CPUs will have an impact of the compile time.
So, the M1 Pro is a great choice for developers. Now I am waiting for the next Mac Pro ...

Jens schrieb am Montag, 6. Dezember 2021 um 10:32:15 UTC+1:
I did some tests with one of my larger GWT projects. It takes 3:55 on my "old" MacBook Pro 16" i9 2.4 GHz, 64 GB RAM. Same project build on a new MacBook Pro M1 Max 64 GB takes roundabout 2:00. That's an incredible improvement. 

Is that project public? Then I would try it with my M1 Pro 32gb which is IMHO the best value for developers, unless you do graphics stuff.

-- J. 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/056f34bd-6777-4489-9050-627754ddad56n%40googlegroups.com.

Re: Performance Comparison GWT Transpiler with MacBook Pro M1 Pro processor

@lofid...@gmail.com

My current machine has an AMD Ryzen 5 5600X, 32GB mem - this was around a 900-1000 euro build from late last year.
I installed the same jdk and used the same mvn (see screenshots)

For normal mvn clean install I had 02:24 and for the mvn -T 1C clean install I had 1:33

I think for another 2-300 euro's for a better processor I could do a lot better still.

Leon.









Op zondag 16 januari 2022 om 02:46:22 UTC+1 schreef Shawn:
Hi,

01:11 min was the best I could get with an Apple M1 Max, 64GB.  

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary for gwt-boot-samples 1.0.0-SNAPSHOT:

[INFO] 

[INFO] gwt-boot-sample-basic .............................. SUCCESS [ 46.823 s]

[INFO] gwt-boot-sample-collection ......................... SUCCESS [01:07 min]

[INFO] gwt-boot-sample-elemento-core ...................... SUCCESS [ 53.763 s]

[INFO] gwt-boot-sample-elemento-template .................. SUCCESS [ 53.487 s]

[INFO] gwt-boot-sample-rxgwt .............................. SUCCESS [01:00 min]

[INFO] gwt-boot-sample-domino-rest ........................ SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-gwtbootstrap3 ................... SUCCESS [01:03 min]

[INFO] gwt-boot-sample-ui-gwtmaterial ..................... SUCCESS [01:08 min]

[INFO] gwt-boot-sample-ui-domino .......................... SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-domino-dagger2 .................. SUCCESS [01:10 min]

[INFO] gwt-boot-sample-ui-vue-gwt ......................... SUCCESS [01:00 min]

[INFO] gwt-boot-sample-ui-dncomponents .................... SUCCESS [01:07 min]

[INFO] gwt-boot-samples ................................... SUCCESS [  0.181 s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time:  01:11 min (Wall Clock)

[INFO] Finished at: 2022-01-15T12:39:42-10:00

[INFO] ------------------------------------------------------------------------

Shawn
On Saturday, January 15, 2022 at 5:38:21 AM UTC-10 lofid...@gmail.com wrote:
@leon.p:

This would be interesting...  Could you try to build the project as I mentioned in my article? To see what time we would get there?

Here is the article: 


and


Record is: 

1. Without -T 1C clean install: 2m21s
2. With -T 1C clean install: 1m13s

Would like to see if someone can get faster than this 😉

Thanks, Lofi
leon.p...@gmail.com schrieb am Samstag, 15. Januar 2022 um 13:19:48 UTC+1:
For around a 1000 euro, you can build a desktop that is faster compiling than any laptop.
And on linux the memory is used a lot more efficient than on a mac, so you need less.
That being said - I have a macbook when I travel. But in the office and at home I switched to working on desktops about 5 yrs ago.



Op woensdag 12 januari 2022 om 09:12:42 UTC+1 schreef Shawn:
I kinda like the Max 64GB.  I'm pushing 54GB used for eclipse (running an appengine dev and GWT server) during a build.  My upload to google cloud is slow so after the build I can easily start developing again while it's deploying.

I also use a ramdisk and set the GWT SuperDev mode to use that with  -workDir /Users/me/.tmpdisk/GWT_RAM_DISK.  Then build with an ant task and add this to the gwtc java task for building.

<sysproperty key="gwt.persistentunitcachedir" value="/Users/me/.tmpdisk/GWT_RAM_DISK"/>


No benchmarks but probably the biggest benefit is debugging which I still do in Eclipse via SDGB.

I haven't been able to get Eclipse to run natively as macOS AArch64 is only available from the 2021-12 version which just borks my project.  It seems to be a conflict with the google-cloud-plugin I use for appengine.  Still 2021-09 with emulated Eclipse is a major improvement especially since the dev server and build processes can be run natively.

Anyway, 32GB on a pro ordered today is about a month to get delivery and 64GB on a max is about two months.  I got a 64GB max with 32 GPUs (maybe I can use those for machine learning) as it was the only way to get more than 16GB of memory without waiting so long and I had to move suddenly and couldn't bring my iMac.  

On Tue, Jan 11, 2022 at 9:17 AM 'Frank Hossfeld' via GWT Users <google-we...@googlegroups.com> wrote:
No, sorry ... closed source. Yep, I agree with. Don't think, that the graphics CPUs will have an impact of the compile time.
So, the M1 Pro is a great choice for developers. Now I am waiting for the next Mac Pro ...

Jens schrieb am Montag, 6. Dezember 2021 um 10:32:15 UTC+1:
I did some tests with one of my larger GWT projects. It takes 3:55 on my "old" MacBook Pro 16" i9 2.4 GHz, 64 GB RAM. Same project build on a new MacBook Pro M1 Max 64 GB takes roundabout 2:00. That's an incredible improvement. 

Is that project public? Then I would try it with my M1 Pro 32gb which is IMHO the best value for developers, unless you do graphics stuff.

-- J. 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c0b5e13d-8572-4d45-ab68-9c2aae06cf4cn%40googlegroups.com.

Saturday, January 15, 2022

Re: Performance Comparison GWT Transpiler with MacBook Pro M1 Pro processor

Hi,

01:11 min was the best I could get with an Apple M1 Max, 64GB.  

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary for gwt-boot-samples 1.0.0-SNAPSHOT:

[INFO] 

[INFO] gwt-boot-sample-basic .............................. SUCCESS [ 46.823 s]

[INFO] gwt-boot-sample-collection ......................... SUCCESS [01:07 min]

[INFO] gwt-boot-sample-elemento-core ...................... SUCCESS [ 53.763 s]

[INFO] gwt-boot-sample-elemento-template .................. SUCCESS [ 53.487 s]

[INFO] gwt-boot-sample-rxgwt .............................. SUCCESS [01:00 min]

[INFO] gwt-boot-sample-domino-rest ........................ SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-gwtbootstrap3 ................... SUCCESS [01:03 min]

[INFO] gwt-boot-sample-ui-gwtmaterial ..................... SUCCESS [01:08 min]

[INFO] gwt-boot-sample-ui-domino .......................... SUCCESS [01:11 min]

[INFO] gwt-boot-sample-ui-domino-dagger2 .................. SUCCESS [01:10 min]

[INFO] gwt-boot-sample-ui-vue-gwt ......................... SUCCESS [01:00 min]

[INFO] gwt-boot-sample-ui-dncomponents .................... SUCCESS [01:07 min]

[INFO] gwt-boot-samples ................................... SUCCESS [  0.181 s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time:  01:11 min (Wall Clock)

[INFO] Finished at: 2022-01-15T12:39:42-10:00

[INFO] ------------------------------------------------------------------------

Shawn
On Saturday, January 15, 2022 at 5:38:21 AM UTC-10 lofid...@gmail.com wrote:
@leon.p:

This would be interesting...  Could you try to build the project as I mentioned in my article? To see what time we would get there?

Here is the article: 


and


Record is: 

1. Without -T 1C clean install: 2m21s
2. With -T 1C clean install: 1m13s

Would like to see if someone can get faster than this 😉

Thanks, Lofi
leon.p...@gmail.com schrieb am Samstag, 15. Januar 2022 um 13:19:48 UTC+1:
For around a 1000 euro, you can build a desktop that is faster compiling than any laptop.
And on linux the memory is used a lot more efficient than on a mac, so you need less.
That being said - I have a macbook when I travel. But in the office and at home I switched to working on desktops about 5 yrs ago.



Op woensdag 12 januari 2022 om 09:12:42 UTC+1 schreef Shawn:
I kinda like the Max 64GB.  I'm pushing 54GB used for eclipse (running an appengine dev and GWT server) during a build.  My upload to google cloud is slow so after the build I can easily start developing again while it's deploying.

I also use a ramdisk and set the GWT SuperDev mode to use that with  -workDir /Users/me/.tmpdisk/GWT_RAM_DISK.  Then build with an ant task and add this to the gwtc java task for building.

<sysproperty key="gwt.persistentunitcachedir" value="/Users/me/.tmpdisk/GWT_RAM_DISK"/>


No benchmarks but probably the biggest benefit is debugging which I still do in Eclipse via SDGB.

I haven't been able to get Eclipse to run natively as macOS AArch64 is only available from the 2021-12 version which just borks my project.  It seems to be a conflict with the google-cloud-plugin I use for appengine.  Still 2021-09 with emulated Eclipse is a major improvement especially since the dev server and build processes can be run natively.

Anyway, 32GB on a pro ordered today is about a month to get delivery and 64GB on a max is about two months.  I got a 64GB max with 32 GPUs (maybe I can use those for machine learning) as it was the only way to get more than 16GB of memory without waiting so long and I had to move suddenly and couldn't bring my iMac.  

On Tue, Jan 11, 2022 at 9:17 AM 'Frank Hossfeld' via GWT Users <google-we...@googlegroups.com> wrote:
No, sorry ... closed source. Yep, I agree with. Don't think, that the graphics CPUs will have an impact of the compile time.
So, the M1 Pro is a great choice for developers. Now I am waiting for the next Mac Pro ...

Jens schrieb am Montag, 6. Dezember 2021 um 10:32:15 UTC+1:
I did some tests with one of my larger GWT projects. It takes 3:55 on my "old" MacBook Pro 16" i9 2.4 GHz, 64 GB RAM. Same project build on a new MacBook Pro M1 Max 64 GB takes roundabout 2:00. That's an incredible improvement. 

Is that project public? Then I would try it with my M1 Pro 32gb which is IMHO the best value for developers, unless you do graphics stuff.

-- J. 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e80f0dea-df01-4f34-bba8-62303ab0da54n%40googlegroups.com.