Re: Really need help getting CodeServer to run with Java 11 and GWT 2.10

['RobW' via GWT Users]

Note sure if this will gelp you much - we're a Gradle user, and don't use 
intellij. But the basic principles are the same.

When we migrated to the latest GWT we also updated our top level gradle 
build file to have a gwtSuperDev task which does all the heavy lifting for 
us:

task gwtSuperDev(dependsOn: 'build') {
// probably a nicer way of getting these (e.g through project 
sourcepaths)
def gwtapi_src = file('tas/gwtapi/src')
def webui_src = file('webui/src')

doLast {
def compilerArgs = [
"-strict", "-noincremental", "-noprecompile", 
"-src", "${gwtapi_src}/", 
"-src", "${webui_src}/", 
"com.ascert.webui.vt.VtWebUi-dev" 
]

javaexec {
main = 'com.google.gwt.dev.codeserver.CodeServer'
// Leverage the Gradle create classpaths for gwtapi and 
webui subprojects
// Make sure GWT build libs are at the front to ensure the 
vanilla GWT jetty classes are used by codeserver
classpath += configurations.gwtBuild
// These classpaths will duplicate some of the above, but 
doing this way ensures our custom jetty does not get 
// picked up by GWT codeserver, which causes class 
inconsistencies.
classpath += 
project(':proj:webui').configurations.compileClasspath
classpath += 
project(':proj:tas:gwtapi').configurations.compileClasspath

maxHeapSize = "1000m"

args = compilerArgs.flatten()
}
}
}

Our 2 main source trees are defined by gwtapi_src and webui_src. The 
com.ascert.webui.vt.VtWebUi-dev 
is our dev GWT XML file name. It's slightly different to our prod one as it 
has debug flags on and only creates a single large permutation.

That's really the main part. We also have the source modules on the 
classpath as :proj:webui and :proj:gwtapi - for reasons as per the comments.

The only other crucial part is the configurations.gwtBuild. This is a 
gradle configuration with all the JARs needed for codeserver (gwt_dev, 
gwt_user, various js lib jars such as GXT etc.). It's really just a 
convenient way of handling classpath JARs and nothing more. If/when we 
update the versions of any of those, the above automatically pulls in the 
updated dependency versions.

There's really nothing that special about CodeServer apart from making sure 
all your own sources and JARs are on the classpath, plus the standard GWT 
ones and any 3rd party libs you use. Although the above is for Gradle, the 
same principles and approach ought to apply for MVN or any other build tool.

Good luck!

-Rob


On Monday 15 April 2024 at 10:13:19 UTC+1 Mathias wrote:

> Hi Thomas
>
> unfortunately, I'm still stuck. I thought I'd attack the Lombok dependency 
> first, since that's a third-party it depends on. I don't suppose you've 
> ever been exposed to that? 
> I tried setting the 
> *compile *to the "configuration" setting 
> of the plugin def in pluginmanagement of the root pom. That didn't help. 
> (neither compile+runtime)
>
> In the intellij GWT-plugin I got it working while running by setting the 
> argument "-javaagent:/...path/lombok-1.16.14.jar=ECJ , not sure if that 
> could change anything. I mean this breaks at compile so I don't know.
>
> I have gone through the configuration line-by line with both your 
> archetype project and the NaluKit Marco tipped me about. I can't see any 
> relevant difference. I don't have *gwt-lib *on any 
> dependency, but neither does any of the other projects I look at.
>
> I also tried adding lombok dependency to the plugin, it didn't help either.
>
> I am basically stuck, this is not great. Would you have time to look at 
> the plugin config if I pasted it?
>
> On Friday 12 April 2024 at 11:20:01 UTC+2 Thomas Broyer wrote:
>
>> On Friday, April 12, 2024 at 7:50:42 AM UTC+2 Mathias wrote:
>>
>> -My dependencies should be ok since i can build it with the plugin, so 
>> i'm a bit at a loss as to how make this work.
>>
>>
>> Dependencies for gwt:compile and gwt:codeserver aren't the same: 
>> https://tbroyer.github.io/gwt-maven-plugin/codeserver.html
>> You might have to either adjust the  of dependencies (e.g. from 
>> provided to compile) or adjust the gwt:codeserver's classpathScope (e.g. 
>> from runtime to compile+runtime or compile)
>>  
>>
>> as a final aside:
>> The "neither a gwt-lib or jar" warning messages in the error log below - 
>> i still get it if i add the gwt-lib type to the dependency, and the 
>> archetype project prints the same error when created.
>>
>>
>> Note that it's an info, not a warning 
>>
>

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

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

['RobW' via GWT Users]

As noted in the post - we didn't get around to trying Domino REST. By the 
time we discovered it, we'd already made the decision to stick with GWT-RPC 
and move on to other work. It's possible we'd revisit that, but we'd 
probably want to see some worked examples of how to transition from GWT-RPC 
to Domino REST. We already burnt quite a few cycles digging into the depths 
of alternates only to find they came up short. So it's hard to justify 
going back there to do more of that at this stage when GWT-RPC still works.

On Tuesday, 25 July 2023 at 15:43:06 UTC+1 Michael Conrad wrote:

> Did y'all test DominoKit? It is actively maintained and has a REST module. 
> I'm curious if you did test it what shortcomings you may have run into.
>
> On Tuesday, July 25, 2023 at 9:23:53 AM UTC-4 RobW wrote:
>
>> We got to a similar point. Looked in depth at moving the GWT front end to 
>> a REST API - but found two big drawbacks: 
>>
>>1. none of the frameworks we could find had async callback handling 
>>similar to GWT-RPC, with common interface classes client server side AND 
>>support JAX-RS subresources. RestyGWT got close apart from those last two 
>>points - there is a model with common client/server interfaces, but it 
>>doesn't support subresources. We found at least 1 other GWT REST toolkit 
>>that had exactly the same issue  - so it's clearly not a trivial one to 
>>solve. 
>>2. somewhat more serious than the first issue was that none of the 
>>GWT REST API frameworks looked to be that actively maintained, at least 
>>tracking their GitHub commits anyhow
>>
>> So ultimately, although REST API an attractive route, GWT-RPC remains 
>> more practical for us in the near term.
>>
>> Note - one we didn't explore in depth but may come back too was Domino 
>> Kit, which has a REST API component. That did look more actively maintained 
>> and perhaps is a way forward.
>>
>> On Monday, 24 July 2023 at 18:50:38 UTC+1 Ralph Fiergolla wrote:
>>
>>> That is, as long as I stay within GWT there is no need to change (and 
>>> loose type checking and convenience). I will happily stay with GWT RPC then!
>>>
>>> R
>>>
>>> Jens  schrieb am Mo. 24. Juli 2023 um 18:24:
>>>

 I think I asked the question before: as a long-term GWT-RPC user, what 
 would be the benefit of moving to some other RPC protocol/mechanism?


 Depends on your situation of course. If you want to use your existing 
 backend with other clients written in other languages then GWT-RPC is a 
 bad 
 fit. While the wire format of GWT-RPC is documented, you still need to 
 write the client code to generate it. Also GWT-RPC supports inheritance 
 which other languages you want to use might not support. Other JS based 
 RPC 
 solutions as well as general purpose solutions like gRPC typically do not 
 support inheritance.

 GWT-RPC will already be annoying if you decide to have some portions of 
 your app being written in a different framework since it is easier to find 
 developers for that framework, e.g. angular, svelte, react, whatever. You 
 would then need to define a JS api that calls into GWT code so these 
 frameworks can talk to your GWT-RPC backend (or you need to provide new 
 endpoints in your backend that do not talk GWT-RPC).

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

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/google-web-toolkit/ab08b131-3904-49b1-8920-b924c7b31c9an%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/692de019-081b-4612-ba19-a9dd3783ac5dn%40googlegroups.com.

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

['RobW' via GWT Users]

We got to a similar point. Looked in depth at moving the GWT front end to a 
REST API - but found two big drawbacks: 

   1. none of the frameworks we could find had async callback handling 
   similar to GWT-RPC, with common interface classes client server side AND 
   support JAX-RS subresources. RestyGWT got close apart from those last two 
   points - there is a model with common client/server interfaces, but it 
   doesn't support subresources. We found at least 1 other GWT REST toolkit 
   that had exactly the same issue  - so it's clearly not a trivial one to 
   solve. 
   2. somewhat more serious than the first issue was that none of the GWT 
   REST API frameworks looked to be that actively maintained, at least 
   tracking their GitHub commits anyhow
   
So ultimately, although REST API an attractive route, GWT-RPC remains more 
practical for us in the near term.

Note - one we didn't explore in depth but may come back too was Domino Kit, 
which has a REST API component. That did look more actively maintained and 
perhaps is a way forward.

On Monday, 24 July 2023 at 18:50:38 UTC+1 Ralph Fiergolla wrote:

> That is, as long as I stay within GWT there is no need to change (and 
> loose type checking and convenience). I will happily stay with GWT RPC then!
>
> R
>
> Jens  schrieb am Mo. 24. Juli 2023 um 18:24:
>
>>
>> I think I asked the question before: as a long-term GWT-RPC user, what 
>> would be the benefit of moving to some other RPC protocol/mechanism?
>>
>>
>> Depends on your situation of course. If you want to use your existing 
>> backend with other clients written in other languages then GWT-RPC is a bad 
>> fit. While the wire format of GWT-RPC is documented, you still need to 
>> write the client code to generate it. Also GWT-RPC supports inheritance 
>> which other languages you want to use might not support. Other JS based RPC 
>> solutions as well as general purpose solutions like gRPC typically do not 
>> support inheritance.
>>
>> GWT-RPC will already be annoying if you decide to have some portions of 
>> your app being written in a different framework since it is easier to find 
>> developers for that framework, e.g. angular, svelte, react, whatever. You 
>> would then need to define a JS api that calls into GWT code so these 
>> frameworks can talk to your GWT-RPC backend (or you need to provide new 
>> endpoints in your backend that do not talk GWT-RPC).
>>
>> -- 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/ab08b131-3904-49b1-8920-b924c7b31c9an%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/169620a5-7a0b-4927-b22b-ac1d8a26ffc6n%40googlegroups.com.

Re: GWT compilation error with JDK 11

['RobW' via GWT Users]

I can't comment on the Eclipse plugin side of things, because we don't use 
those. But I can confirm that basic GWT 2.9/2.10 compilation works fine 
under Java 11 - that's our main Java platform now. I do recall some 
migration notes in the GWT 2.9 or 2.10 release notes we had to take care 
over, but I don't think those were Java version specific. More a case of 
changes in GWT packaging.

On Tuesday, 11 July 2023 at 23:47:37 UTC+1 Ying Jin wrote:

> Ralph, thanks very much for your suggestion. I'll look into more of the 
> approach to convert our gwt project to maven project.
>
> BTW, I've found the solution to make the GWT plugin work again in my 
> laptop to compile the GWT project.
>
> I came across the following post when searching for the error related to 
> webappcreator. 
>
> After I removed the "classpath" system variable from my new laptop and 
> moved the GWT SDK to the top of the build path, the GWT Compiler starts 
> working to compile the GWT project. 
>
>
> https://topic.alibabacloud.com/a/exception-invocation-of-font-colorredcomfont-font-colorredgooglefont-gwt-user-font-colorredtoolsfont-webappcreator-failed-see-the-error-log-for-more-details_8_8_31771273.html
>
> Cheers ,
> Jenny
>
>
> On Tuesday, July 11, 2023 at 12:45:24 PM UTC-5 Ralph Fiergolla wrote:
>
>>
>> It should not be that hard actually: you probably have separated client, 
>> shared and server side classes following the standard package naming 
>> convention. That is, basically it will be sufficient to copy your source 
>> code to the according client/shared/server sub projects and you are done. 
>> Okay, devil is in the details, but I did the same with some legacy project 
>> and happily live ever after. Give it a try. Definitely better than spending 
>> more time on installing different eclipse versions and plug-ins.
>> Cheers
>> Ralph 
>> On Tuesday, July 11, 2023 at 6:51:11 PM UTC+2 Ying Jin wrote:
>>
>>> Ralph,
>>>
>>> Thanks for your suggestion. However, one of our GWT project in 
>>> production was developed long time ago and has very big codebase. I'm not 
>>> sure how hard to convert it to Maven oriented project. It seems that we 
>>> have to do lots of code refactoring 
>>> in order to separate client side and server side code and other 
>>> configuraitons. 
>>>
>>> thanks,
>>> Jenny
>>>
>>> On Monday, July 10, 2023 at 11:59:01 PM UTC-5 Ralph Fiergolla wrote:
>>>
 Hi Jenny!
 With all these issues related to out-dated Eclipse plug-ins I would 
 strongly suggest switching to the new GWT Maven plug-in instead. Follow 
 the 
 instructions https://github.com/tbroyer/gwt-maven-archetypes/ to 
 create a project that you can easily import into the most recent Eclipse 
 (or any other IDE) subsequently. I don’t see much support for Eclipse 
 plug-ins coming… I learned it the hard way too but am now happily working 
 the Maven way. 
 Bon courage!
 Ralph 
 On Monday, July 10, 2023 at 7:25:41 PM UTC+2 Ying Jin wrote:

> Hi Colin,
>
> I posted this issue on the gwt plugin site below, but there is no 
> reply yet.
>
> https://github.com/gwt-plugins/gwt-eclipse-plugin/issues/470
>
> In addition, I've tried to install other version of Eclipse such as 
> Eclipse 4.18 (2020-12) with a new workspace. After I installed GWT plugin 
> 3 
> from market place and tried to create a sample gwt web application 
> project 
> as described below in gwt site, I got the error " Invocation of 
> com.google.gwt.user.tools.WebAppCreator failed. See the error log for 
> more 
> details."  It seems to me this current market place gwt plugin didn't 
> work 
> as I didn't use our project at all
> and followed the tutorial below.
>
> https://www.gwtproject.org/usingeclipse.html
>
> Is there a way to get a working GWT plugin for Eclipse which can work 
> with JDK 11?
>
> Your help is much appreciated!
> Jenny
> On Tuesday, July 4, 2023 at 12:43:05 PM UTC-5 Colin Alworth wrote:
>
>> If the class can't be found, something is wrong with your gwt-dev, or 
>> the gwt-dev isn't on the classpath, or more details from the error 
>> message 
>> will indicate why the Compiler class couldn't be loaded. 
>>
>> Please file a bug with more details (logs, full error message, other 
>> details about differences between the working computer and non-working 
>> computer) at https://github.com/gwt-plugins/gwt-eclipse-plugin/ so 
>> contributors there can take a closer look?
>>
>> On Sunday, July 2, 2023 at 2:28:44 PM UTC-5 jiny...@gmail.com wrote:
>>
>>> I tried to reinstall Eclipse again and GWT 3 plugin again from 
>>> Eclipse market, downloaded and reinstalled gwt 2.9 for the project, 
>>> however, I still encountered the error below.
>>> It is so weird, the project configuration in eclipse works in my old 
>>> laptop, not in the new one 

Re: JavaFX for GWT

['RobW' via GWT Users]

Interesting stuff. Have looked at Vaadin and WebSwing (commercial) in the 
past - but yours is an interesting take/approach. Will be good to see how 
it progresses.

On Wednesday, 9 November 2022 at 12:39:48 UTC Jonathan Franchesco Torres 
Bca wrote:

> Hi,
>
> And what about JFC Swing which is interoperable with JavaFX.
> I have a desktop application that mixes both and we use substance to 
> improve the display of the controls
> I leave an example
> [image: image.png]
>
>  
>
>  *   
>    
>  *
>
> Jonathan Franchesco Torres Baca(@jofrantoba)
>
> CIO - Kiongo Technology
>
> *Jr Juan Voto Bernales 344 - La Victoria, Lima - Perú*
>
> Teléfono   *+5116357857 <+51%201%206357857>*
>
> Cel.+51929913524 <+51%20929%20913%20524>
>
>
> El mar, 8 nov 2022 a las 9:38, Bruno Salmon () 
> escribió:
>
>> Hi,
>>
>> I'm working on a JavaFX transpiler powered by GWT.
>> It lets you use JavaFX as a UI toolkit in your GWT apps.
>> The JavaFX API is far from completely covered, but you can already see 
>> some interesting results.
>>
>> The project is on GitHub for those who are interested.
>> https://github.com/webfx-project/webfx
>>
>> If you have any questions, please let me know.
>>
>> -- 
>>
> 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 on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/8210a6a2-ad1a-4b2d-ba68-19dcc5fbeef3n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/03a9911c-350f-47c6-9f42-f8189e88a135n%40googlegroups.com.

Re: Javascript module function in GWT with JsInterop

['RobW' via GWT Users]

Nice - actually proved a very decent little library for us, and easy to 
embed on the 2 panels where we wanted context sensitive coloring. We even 
got syntax error markers in the margins working - our server code already 
parsed and reported lines in error, so it was just a case of figuring the 
Codejar API to add the markers to the associated lines. We were a bit short 
of time, so we ended up using a minimal set of old-stype JSNI method 
wrappings for the 7 or 8 native methods we needed. JsInterop would 
obviously be a tidier and more modern way to go of course.

On Wednesday, 21 April 2021 at 15:33:59 UTC+1 Thomas wrote:

> Ok, cool. Coincidentally I also want to use CodeJar, so I can work that 
> out ;) Cheers!
>
> On Wednesday, April 21, 2021 at 10:25:48 PM UTC+8 RobW wrote:
>
>> From memory, I think we took the easy way around and fell back to the 
>> non-module version of the underlying JS, which fortunately were available 
>> for the lib we were using. Those then just got added to the other JS files 
>> we include direct on our app's base HTML.
>>
>> On Wednesday, 21 April 2021 at 15:18:53 UTC+1 Thomas wrote:
>>
>>> Hi Rob, good to hear. How did you solve the import of the module?
>>>
>>> On Tuesday, November 3, 2020 at 1:19:53 AM UTC+8 RobW wrote:
>>>
 Thomas has very kindly posted an answer to the above SO thread. So I 
 think I'm good!

 On Monday, 2 November 2020 at 10:26:56 UTC RobW wrote:

> Just re-posting a Q I put on SO today in case anyone here has insights:
>
>
> https://stackoverflow.com/questions/64643227/javascript-module-function-in-gwt-with-jsinterop
>
> Basically, battling to figure how to integrate a library that is 
> implemented as a Javascript export function using JS modules into a GWT 
> application using JsInterop. Pretty sure there must be some way, but the 
> combination of JS module syntax/usage, lack of global namespace for JS 
> module functions is baffling me. I'm a long time Java/GWT coder, but with 
> less in depth JS knowledge. All of my JS integration in the past was done 
> with the older JSNI / wrappering approaches.
>


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/7fc4cc38-b9c3-4e88-8b5f-cc7a0405359cn%40googlegroups.com.

Re: Javascript module function in GWT with JsInterop

['RobW' via GWT Users]

>From memory, I think we took the easy way around and fell back to the 
non-module version of the underlying JS, which fortunately were available 
for the lib we were using. Those then just got added to the other JS files 
we include direct on our app's base HTML.

On Wednesday, 21 April 2021 at 15:18:53 UTC+1 Thomas wrote:

> Hi Rob, good to hear. How did you solve the import of the module?
>
> On Tuesday, November 3, 2020 at 1:19:53 AM UTC+8 RobW wrote:
>
>> Thomas has very kindly posted an answer to the above SO thread. So I 
>> think I'm good!
>>
>> On Monday, 2 November 2020 at 10:26:56 UTC RobW wrote:
>>
>>> Just re-posting a Q I put on SO today in case anyone here has insights:
>>>
>>>
>>> https://stackoverflow.com/questions/64643227/javascript-module-function-in-gwt-with-jsinterop
>>>
>>> Basically, battling to figure how to integrate a library that is 
>>> implemented as a Javascript export function using JS modules into a GWT 
>>> application using JsInterop. Pretty sure there must be some way, but the 
>>> combination of JS module syntax/usage, lack of global namespace for JS 
>>> module functions is baffling me. I'm a long time Java/GWT coder, but with 
>>> less in depth JS knowledge. All of my JS integration in the past was done 
>>> with the older JSNI / wrappering approaches.
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c54462b1-680c-4cd0-8e87-e5fb3e63afacn%40googlegroups.com.

Re: Updated GXT for GWT 2.9.0 and Java 11

['RobW' via GWT Users]

My post was purely to inform others that it is available - not as a comment 
on the quality (or otherwise) of GXT and the Sencha support. I have no 
affiliation with them, we are just a user of the library.

On Thursday, 25 February 2021 at 10:43:41 UTC Luca Morettoni wrote:

> hello, we still using GXT 4.0.2, and we waited years a fix version because 
> 4.0.3 was a total failure… now we decided to move to “something else”, but 
> we still evaluating different (commercial and not) solutions to replace the 
> client widgets infrastructure.
> Also we had a very BAD experience with their support, we paid the fee for 
> years, and in the last times we got a very LIMITED support!
>
> In any case, we are using GXT 4.0.2 and GWT 2.9.0 for a long time without 
> any issue, but we never tested it under Java 11...
>
>
> On 25 Feb 2021, at 07:56, 'RobW' via GWT Users <
> google-we...@googlegroups.com> wrote:
>
> Not sure how many of you also use GXT, but just spotted an announcement 
> from Sencha that GXT 4.1 is out, with support for GWT 2.9.0 and Java 11 
> (although the latter is marked as a "should support").
>
> In the middle of some othe rwork, so have yet to try it in our setup. Will 
> report back once we have though. FWIW - we've been building and running 
> under GWT 2.9.0 fine with the previous 4.0 version, so I'm not really 
> expecting any issues from that side of things.
>
>
>
>
> --
> Luca Morettoni  | http://www.morettoni.net
> http://it.linkedin.com/in/morettoni/ | http://twitter.com/morettoni
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/df7e56b2-e823-44c3-b507-b893684b57cfn%40googlegroups.com.

Updated GXT for GWT 2.9.0 and Java 11

['RobW' via GWT Users]

Not sure how many of you also use GXT, but just spotted an announcement 
from Sencha that GXT 4.1 is out, with support for GWT 2.9.0 and Java 11 
(although the latter is marked as a "should support").

In the middle of some othe rwork, so have yet to try it in our setup. Will 
report back once we have though. FWIW - we've been building and running 
under GWT 2.9.0 fine with the previous 4.0 version, so I'm not really 
expecting any issues from that side of things.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f1e4a9f4-790d-472b-9ef4-9b7b0049a922n%40googlegroups.com.

Re: Our 10+ year journey with GWT (+ job opening)

['RobW' via GWT Users]

Similar decision process for us. After a lot of research into Vue, React 
etc we decided the switch over and learning curve just didn't pay back. Our 
app scaffold in GWT is actually really solid, and it's easier for us to add 
more modern approaches like a JSON based REST API and newer layouts and 
widgets (like Material Design) into that framework rather than throw it all 
away. A big benefit is we can do it step by step, panel by panel too if we 
want - making it much more manageable to refresh the overall app.
On Friday, 22 January 2021 at 06:53:34 UTC Marco Castillo wrote:

> It is nice to hear all this experience with GWT. I would like to share 
> mine. I'm based in Guatemala, our development team develop a product, 
> Axeso, it is a product that enhances the security in Google Apps (next 
> GSuite, now Google Workspace). We develop the administrator console using 
> GWT, the backend in Google App Engine using java mainly and NoSQL 
> databases, and at this time (almost ten years later) we're deciding what 
> new framework would be the successor of GWT.
> I was considering https://gwtmaterialdesign.github.io/gwt-material-demo/, 
> we would like to give our console a more material design look. And with all 
> the stories I just read, maybe I will ditch React (it was going to be our 
> choosed framework for substituting GWT) and kept GWT.
> Regards
>
>
> Marco
> On Wednesday, January 20, 2021 at 10:14:32 AM UTC-6 David Nouls wrote:
>
>> That is actually a good point indeed. We also have very old tech in 
>> production including some ALGOL.
>>
>> I do have the impression that the JS Frameworks race has been slowing 
>> down a bit. Sure there will always be some new ideas, but the big 
>> frameworks are there for quite some.
>>
>> At least with GWT/Java it is rather easy to maintain! GWT does not change 
>> much, sometimes that is an advantage.
>> On 20 Jan 2021, 16:48 +0100, lofid...@gmail.com , 
>> wrote:
>>
>> IMHO that's the problem with frameworks / languages. If they are "strong 
>> enough" they won't be gone... I don't think that TypeScript / Vue.js / 
>> React / Angular etc. will be vanished. They will stay forever just like 
>> COBOL and other technologies like Borland / Embarcadero Delphi Object 
>> Pascal. My comment above was a joke, because I don't know what will happen 
>> in 10 years. There will be another hot things. Maybe we move completely on 
>> the native client development instead of Web browser? But who knows...
>>
>> So at the end of the day the devs need to maintain apps with the zoo of 
>> frameworks and languages.  
>>
>> Scary if you see this history of web frameworks: 
>> https://raw.githubusercontent.com/mraible/history-of-web-frameworks-timeline/master/history-of-web-frameworks-timeline.png
>>
>> I think, it's time that the development of apps / Web apps should go 
>> higher in the abstraction level to be technology / framework independent. 
>> PIM (Platform Independent Model) anyone?  
>>
>> BTW.: I still have JSPs in production. Also COBOL 
>>
>> Cheers,
>> Lofi
>> t.br...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 14:36:30 UTC+1:
>>
>>> Why did you bet on GWT 10 years ago and wouldn't bet on TypeScript 
>>> nowadays? 
>>> (fwiw, TypeScript is already 8 years old; Vue.js is 6 years old, React 
>>> is 7)
>>>
>>> On Tuesday, January 19, 2021 at 5:26:38 PM UTC+1 lofid...@gmail.com 
>>> wrote:
>>>
 @swas... 

 
 Yes, almost 10 years for me too and production application  running for 
 3 years.
 GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
 my next 10 years plan is  move to TypeScript + VueJS.
 

 After 10 years, will we still be able to see TypeScript + VueJS? 

 Cheers,
 Lofi
 RobW schrieb am Dienstag, 19. Januar 2021 um 15:29:42 UTC+1:

> Our web front end is on 15 years with GWT as of this year, and we're 
> expecting 5 more with luck. So we'll hit the 20 year mark if all goes well
>
> On Tuesday, 19 January 2021 at 10:46:44 UTC aka...@gmail.com wrote:
>
>> I wonder if that will actually last for the next 10 years.
>>
>> On Tuesday, January 19, 2021 at 10:04:19 AM UTC+2 swas...@gmail.com 
>> wrote:
>>
>>> Yes, almost 10 years for me too and production application  running 
>>> for 3 years.
>>> GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
>>> my next 10 years plan is  move to TypeScript + VueJS. 
>>> On Monday, 4 January 2021 at 23:37:53 UTC+7 Alexander Bertram wrote:
>>>
 Nice to hear from everyone!

 Here's to the next ten years :-)

 Best wishes for 2021,
 Alex

 On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq 
 Sobulo wrote:

>
> I've been using GWT for 7+ years (with appengine java backends) 
> and actively looking for a job. I'll push my resume. 
>
> Thanks

Re: Our 10+ year journey with GWT (+ job opening)

['RobW' via GWT Users]

Our web front end is on 15 years with GWT as of this year, and we're 
expecting 5 more with luck. So we'll hit the 20 year mark if all goes well

On Tuesday, 19 January 2021 at 10:46:44 UTC aka...@gmail.com wrote:

> I wonder if that will actually last for the next 10 years.
>
> On Tuesday, January 19, 2021 at 10:04:19 AM UTC+2 swas...@gmail.com wrote:
>
>> Yes, almost 10 years for me too and production application  running for 3 
>> years.
>> GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
>> my next 10 years plan is  move to TypeScript + VueJS.
>> On Monday, 4 January 2021 at 23:37:53 UTC+7 Alexander Bertram wrote:
>>
>>> Nice to hear from everyone!
>>>
>>> Here's to the next ten years :-)
>>>
>>> Best wishes for 2021,
>>> Alex
>>>
>>> On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq Sobulo 
>>> wrote:
>>>

 I've been using GWT for 7+ years (with appengine java backends) and 
 actively looking for a job. I'll push my resume.

 Thanks
 On Monday, 21 December 2020 at 15:24:19 UTC+1 aka...@gmail.com wrote:

> We are in times where working remotly id actually a good option.
>
> On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote:
>
>> Hi Alex,
>>
>> Same story here. I have been working with GWT since it first came 
>> out. For our current project we again opted for GWT because we share a 
>> lot 
>> of code between client and server and productivity is high.
>>
>> I’m not available at the moment (maybe end of next year)… but living 
>> in Belgium/Leuven I don’t think that is doable. Relocation is not an 
>> option. Good luck finding people, there are not a lot on the market.
>>
>> Groeten,
>> David
>> On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users <
>> google-we...@googlegroups.com>, wrote:
>>
>>
>> Dear all,  
>>
>> I hope this email isn't too off-topic, but I wanted to share an 
>> opening for a job on our team with a large GWT component.
>>
>> https://jobs.bedatadriven.com/software-engineer
>>
>> The first version of our product, ActivityInfo, a data collection and 
>> analysis platform for humanitarian relief, was built with GWT, GXT and 
>> Google Gears in 2009 and seriously would not have been possible without 
>> GWT. 
>>
>> In 2018, nearly 10 years later, we looked at the amazing js ecosystem 
>> and considered moving to Typescript or Elm.
>>
>> Instead, we decided to keep the bits that we loved about GWT: the 
>> typesafety, code-reuse with the server, i18n, code splitting, linkers, 
>> and 
>> the amazing compiler, and add SCSS for styles and our own port of Preact 
>> + 
>> rxJava-like reactivity for dom manipulation using Elemental2.
>>
>> Three years after the start of ActivityInfo 4.0 we couldn't be 
>> happier with the choice, and are more productive than ever. 
>>
>> If you're an experienced GWT developer that would enjoy the challenge 
>> of a working on a modern GWT codebase, I hope you'll consider joining 
>> our 
>> team!
>>
>>
>> Best,
>> Alex
>>
>> --
>> 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 on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/46240bd9-f716-4448-a481-acfc87229f8fn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/31985d46-5669-4360-b054-ae9e0de678c0n%40googlegroups.com.

Re: Javascript module function in GWT with JsInterop

['RobW' via GWT Users]

Thomas has very kindly posted an answer to the above SO thread. So I think 
I'm good!

On Monday, 2 November 2020 at 10:26:56 UTC RobW wrote:

> Just re-posting a Q I put on SO today in case anyone here has insights:
>
>
> https://stackoverflow.com/questions/64643227/javascript-module-function-in-gwt-with-jsinterop
>
> Basically, battling to figure how to integrate a library that is 
> implemented as a Javascript export function using JS modules into a GWT 
> application using JsInterop. Pretty sure there must be some way, but the 
> combination of JS module syntax/usage, lack of global namespace for JS 
> module functions is baffling me. I'm a long time Java/GWT coder, but with 
> less in depth JS knowledge. All of my JS integration in the past was done 
> with the older JSNI / wrappering approaches.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/5af51388-ad3f-4a05-9434-e66110ec6b99n%40googlegroups.com.

Javascript module function in GWT with JsInterop

['RobW' via GWT Users]

Just re-posting a Q I put on SO today in case anyone here has insights:

https://stackoverflow.com/questions/64643227/javascript-module-function-in-gwt-with-jsinterop

Basically, battling to figure how to integrate a library that is 
implemented as a Javascript export function using JS modules into a GWT 
application using JsInterop. Pretty sure there must be some way, but the 
combination of JS module syntax/usage, lack of global namespace for JS 
module functions is baffling me. I'm a long time Java/GWT coder, but with 
less in depth JS knowledge. All of my JS integration in the past was done 
with the older JSNI / wrappering approaches.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/b66e1077-e2c0-4053-8d62-21134b5acd09n%40googlegroups.com.