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: , >>> 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%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+unsubscr...@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.
Re: Building a GWT project in Eclipse 2019-03+ with Java 11.
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: ,
>> 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%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+unsubscr...@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.
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
Re: New Article "10 Best Java Frameworks to Use in 2021"
We ended up using no plugins for GWT with Gradle. Even if there are some,
none of them fit well.
Luckily, GWT compiler has a nice CLI, so...
Also, we make the gwt a subproject, as we don't use GWT RPC anyway. This
helps keeping gwt-dev out of any runtime classpath!!!
Below is a trimmed version (not sure it even compiles, and it is the
build.gradle for a subproject) of the build.gradle file for reference, for
both compilation (even with a system flag to compile only the dev module)
and for running the super dev mode:
ext {
buildWebapp = "${project(':web').buildDir}/generated/webapp"
gwtDev = Boolean.getBoolean('gwt.development')
}
configurations {
gwt
}
dependencies {
gwt(project(':api')) { transitive = false }
gwt files(project.sourceSets.main.java.srcDirs)
gwt files(project.sourceSets.main.resources.srcDirs)
gwt files(project(':api').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/gwt"
}
group = 'Build'
description = 'Compile the GWT source'
inputs.files configurations.gwt
inputs.property 'development', gwtDev
outputs.dir outDir
classpath = configurations.gwt
main = 'com.google.gwt.dev.Compiler'
args = []
args += ['-sourceLevel', "1.$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.example.MyModuleDev']
} else {
args += ['-style', 'OBFUSCATED']
args += ['-optimize', '9']
args += ['-XnoclassMetadata']
args += ['org.example.MyModule']
}
}
task cleanGwtTemp {
doLast {
ant.delete(dir: "$buildWebapp/gwt")
ant.delete(dir: "$buildDir/tmp/gwt")
}
}
clean {
dependsOn cleanGwtTemp
}
task gwtSuperDev(type: JavaExec) {
dependsOn compileJava
description = 'Run the GWT code server for Super Dev Mode'
classpath = configurations.gwt
main = 'com.google.gwt.dev.codeserver.CodeServer'
args = []
args += ['-sourceLevel', "1.$javaVersion"]
args += ['-launcherDir', buildWebapp]
args += ['-logLevel', 'INFO']
args += ['-workDir', "$buildDir/tmp/gwt"]
args += ['-precompile']
args += ['-failOnError']
args += ['-bindAddress', '0.0.0.0']
args += ['org.example.MyModuleDev']
doFirst {
file("$buildDir/tmp/gwt").mkdirs()
}
}
Em quarta-feira, 10 de março de 2021 às 12:44:57 UTC-3, aka...@gmail.com
escreveu:
> Even if it is opinionated, please give us Gradle GWT archetype. :-)
>
> On Wednesday, March 10, 2021 at 5:25:47 PM UTC+2 t.br...@gmail.com wrote:
>
>>
>>
>> On Wednesday, March 10, 2021 at 4:13:03 PM UTC+1 pavel@gmail.com
>> wrote:
>>
>>> We had the same problem with maven but at the end, maven's multi-module
>>> project and profiles helped to solve *hack around* it.
>>>
>>
>> There, fixed it for you
>>
>> Also see https://www.cloudbees.com/blog/maven-profiles-and-maven-way and
>> https://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>>
>> among others, by prominent Maven PMC members.
>> (and yet, gwt-maven-archetypes use a "dev" profile 路, but it's know to
>> be kind of hackish in places due to Maven and jetty-maven-plugin's
>> limitations)
>>
>
--
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/b369da9d-78fc-4d5f-9227-68a47b18dd61n%40googlegroups.com.
Re: Is GWT 3.0 /GWT 2.9 dead?
It is great to know we can use the snapshot with support for Java 11 already! Unfortunately, except for the GWT team and those that follow the project closely, it looks like GWT is stuck at the 2.8.2 release 2.5 years ago, because the GWT official website contains no information on this. Maybe it would be good to put some text in the home page pointing to this. I'm surely much more optimistic now that I know there is an usable updated version. Great work, guys! Em quinta-feira, 20 de fevereiro de 2020 08:01:43 UTC-3, Ahmad Bawaneh escreveu: > > And lets not forget that it is not so long since j2cl was made public. > > On Thursday, February 20, 2020 at 1:00:33 PM UTC+2, Ahmad Bawaneh wrote: >> >> You dont need to maintain a separate branch or code base, you can use the >> latest snapshot which is as stable as a release, i am pretty sure when 2.9 >> is release you will only need to switch version and everything still works, >> if you can use the snapshot for some reason you can use the unofficial >> release as discussed here >> https://groups.google.com/forum/#!topic/google-web-toolkit/qmwiMVofhR8/discussion >> or >> you can fork and release internally. >> >> and the community work, we need to know that the active members in the >> community is small, that is said we could have made a GWT3.0 a lot earlier, >> we could have focused in shipping a working maven plugin for j2cl and call >> the day, but most of the efforts is focused in making sure that old apps >> will be able to migrate to gwt3.0 without much effort and this part in >> specific is very important and very hard and consumes a lot of time, GWT >> apps in general are big apps and making GWT3.0 that only works for new apps >> only or requires app rewrite does not make any sense. >> >> to get more insight on what have been done check this list >> >> https://ci.vertispan.com/ >> >> On Wednesday, February 19, 2020 at 3:21:03 PM UTC+2, Luis Fernando >> Planella Gonzalez wrote: >>> >>> It has always been said that GWT is active when similar questions are >>> asked in the forum. >>> However, given that the last version, 2.8.2, was released on Oct 19, >>> 2017 and was a bugfix for the 2.8.0 version, released on Oct 20, 2016, I >>> can't see it as "active". >>> At least it smells bad! >>> Even the 1.0 release of Elemental can't be used, because it requires >>> newer components than the pre-packaged version. >>> It is a sad thing, because I work on a large project using GWT since its >>> 1.5.0 version, and our project is actively developed and still evolving. >>> I hope GWT 2.9 is out "soon", because we're planning to switch to Java >>> 11 in the coming months, and it would be a burden to maintain a separated >>> Java version only for the frontend part (been there, done that with Java 8). >>> The fact is that since Google left the project, things are way too slow. >>> Understandable, as it is based on best effor from the brave developers, >>> but still disheartening. >>> Still, I don't loose hope that GWT will be still maintained. >>> >>> Em terça-feira, 18 de fevereiro de 2020 12:08:40 UTC-3, Jeff Zemsky >>> escreveu: >>>> >>>> Frank - Thanks for the reply, but it would be good to understand the >>>> plans to complete the GWT 2.9 release - particularly with reference to >>>> Java >>>> 11 support. Any insight there? >>>> >>>> On Monday, January 27, 2020 at 4:23:09 AM UTC-5, Frank Hossfeld wrote: >>>>> >>>>> Atm the community is very active. We are working on GWT modules: >>>>> replacing generators and JSNI, testig the migraed moules against J2CL, >>>>> etc. >>>>> Besides that, many new frameworks are evolving. >>>>> >>>>> Take a look at this rooms: >>>>> https://gitter.im/gwtproject/gwt >>>>> https://gitter.im/vertispan/j2cl >>>>> https://gitter.im/DominoKit/domino >>>>> to get more infos. >>>>> >>>> -- 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/9bf77f8d-2c11-4d1f-98f2-aa1ca188eb43%40googlegroups.com.
Re: Is GWT 3.0 /GWT 2.9 dead?
It has always been said that GWT is active when similar questions are asked in the forum. However, given that the last version, 2.8.2, was released on Oct 19, 2017 and was a bugfix for the 2.8.0 version, released on Oct 20, 2016, I can't see it as "active". At least it smells bad! Even the 1.0 release of Elemental can't be used, because it requires newer components than the pre-packaged version. It is a sad thing, because I work on a large project using GWT since its 1.5.0 version, and our project is actively developed and still evolving. I hope GWT 2.9 is out "soon", because we're planning to switch to Java 11 in the coming months, and it would be a burden to maintain a separated Java version only for the frontend part (been there, done that with Java 8). The fact is that since Google left the project, things are way too slow. Understandable, as it is based on best effor from the brave developers, but still disheartening. Still, I don't loose hope that GWT will be still maintained. Em terça-feira, 18 de fevereiro de 2020 12:08:40 UTC-3, Jeff Zemsky escreveu: > > Frank - Thanks for the reply, but it would be good to understand the plans > to complete the GWT 2.9 release - particularly with reference to Java 11 > support. Any insight there? > > On Monday, January 27, 2020 at 4:23:09 AM UTC-5, Frank Hossfeld wrote: >> >> Atm the community is very active. We are working on GWT modules: >> replacing generators and JSNI, testig the migraed moules against J2CL, etc. >> Besides that, many new frameworks are evolving. >> >> Take a look at this rooms: >> https://gitter.im/gwtproject/gwt >> https://gitter.im/vertispan/j2cl >> https://gitter.im/DominoKit/domino >> to get more infos. >> > -- 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/498010d4-aca5-4430-8707-c61d15a0cffb%40googlegroups.com.
Re: GWT 2.8.0-rc1 and closure compiler
Em quinta-feira, 4 de agosto de 2016 12:03:04 UTC-3, Thomas Broyer escreveu: > > > > On Thursday, August 4, 2016 at 2:21:29 PM UTC+2, Luis Fernando Planella > Gonzalez wrote: >> >> I've always used the closure compiler with past versions (even with >> 2.8.0-beta1, which we have used in production already). >> Now, to my surprise, it is no longer supported in GWT 2.8.0-rc1, as >> there's no mention to it in the release notes ( >> http://www.gwtproject.org/release-notes.html). >> > > We may want to add a note about it; but that was an experimental feature > and those tend to come and go as experiments prove their value or not. > See > https://gwt.googlesource.com/gwt/+/162ccc9c9112a09bf9ea046da95760f5f1886b72%5E%21/ > > for the rationale. > Ok. In our project, we used to enable the closure compiler because the codebase is quite large, and closure compiler helped in reducing further the code size. I don't have the numbers at hand, but the full code size (including all split points) is about 2.8M, and closure compiler reduced some hundred kilobytes from it. > > >> Now the compiler no longer supports the old closure compiler option, but >> has a new -X[no]closureFormattedOutput option. >> > > It's not really new actually: > https://gwt.googlesource.com/gwt/+/6fa611cf9ad7ffa077a7378a100a7ccbd95e3cb3%5E%21/ > I have assumed it was new because it is not present as option in the gwt-maven-plugin (which is updated up to the beta1). > >> I'm guessing closure compiler is no longer integrated in GWT, but it >> still has the option to format for closure to a later (manual) usage of >> closure compiler. >> I'm using the gwt-maven-plugin, which still uses beta1, but explicitly >> changing its dependencies to 2.8.0-rc1 for gwt-user, gwt-dev and >> gwt-codeserver artifacts, making it usable already for rc1. >> I can't, however, pass the new option (I think there's no way to pass >> arbitrary compiler arguments with gwt-maven-plugin) until the maven plugin >> is updated. >> >> What are the new instructions to keep using closure compiler? >> > > There aren't (see comment about -XclosureFormattedOutput in the commit > message that introduced it) > Do you really *need* it? > I was assuming that flag was needed in order to generate code that complies with the closure compiler limitations (https://developers.google.com/closure/compiler/docs/limitations). Maybe that is not the case and I can just invoke the closure compiler manually on the generated GWT code? Should I expect any runtime problems by doing this? -- 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 post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT 2.8.0-rc1 and closure compiler
I've always used the closure compiler with past versions (even with 2.8.0-beta1, which we have used in production already). Now, to my surprise, it is no longer supported in GWT 2.8.0-rc1, as there's no mention to it in the release notes (http://www.gwtproject.org/release-notes.html). Now the compiler no longer supports the old closure compiler option, but has a new -X[no]closureFormattedOutput option. I'm guessing closure compiler is no longer integrated in GWT, but it still has the option to format for closure to a later (manual) usage of closure compiler. I'm using the gwt-maven-plugin, which still uses beta1, but explicitly changing its dependencies to 2.8.0-rc1 for gwt-user, gwt-dev and gwt-codeserver artifacts, making it usable already for rc1. I can't, however, pass the new option (I think there's no way to pass arbitrary compiler arguments with gwt-maven-plugin) until the maven plugin is updated. What are the new instructions to keep using closure compiler? -- 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 post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Next release
"classpath conflict is generally not a valid reason, because the part of GWT that includes Jetty is not concerned about the server side of the applications" Unless you run [Super]DevMode, which runs both in a single JVM, then it is a pain. There are other libs which are bundled in GWT jars, causing some inconveniences too, like IMHO, saying to run with -noserver is not a perfect solution either, because it complicates things, requiring 2 jvms, and don't playing well with RPC and security policies. Having most of people (if not all) using either an IDE plugin or Maven, which can manage the classpath, I don't see a reason to bundle (very old) 3rd party classes in the GTW jar. Em sexta-feira, 16 de outubro de 2015 06:13:38 UTC-3, Thomas Broyer escreveu: > > > On Thursday, October 15, 2015 at 9:25:40 PM UTC+2, bendg25 wrote: >> >> Can you ditch the embedded Jetty server please. >> > > Hmm, no. But it'd be interesting to know the reason for that request. > For example, a classpath conflict is generally not a valid reason, because > the part of GWT that includes Jetty is not concerned about the server side > of the applications, and the part of your application that would need Jetty > is likely its server side. So the answer in such case is to "just" use > different classpaths/build paths for the client and server sides. > -- 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 post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT 2.8 update
I'd like to ask for an update on the planning for 2.8 release. Are there still many missing functionality? What is the tentative release schedule? I'm avid to change our project source level to Java 8, but I'm not confident in using the SNAPSHOT in a release version of our app. Any chances it will be out still in August? Thanks, Luis. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Static vs dynamic String internationalization
That, of course, depends on the application requirement. I work on a very large app which is not (only) used by ourselves, but by other organizations. And on each organization, administrators can change translations on the fly - just a F5 or logout / login away. In this scenario, of course, there is no choice. We even created a custom translations loading mechanism that efficiently use the browser cache and load translations in parts, as there are more than 4k keys, as we don't want all them to be always downloaded. Each page (it all started in GWT 1.5, before GWT places existed) knows which translation part it needs, so we guarantee to load the required translations before showing the page. But, I agree, it is a very specific requirement. Maybe 99% of the applications are fine with static internationalization. We're part of the other 1%. -- Luis Em segunda-feira, 23 de fevereiro de 2015 19:33:34 UTC-3, Jens escreveu: - The big advantage of dynamic internationalization to me, is that I can store my translations in a database, and update texts without the need of stopping servers to deploy a new compiled version of my application. Not sure if its that big of an advantage. IMHO translations rarely change and the number of supported languages is probably already known upfront and does not change often either. Also if done right, updating an app does not cause any downtime especially if only translations have changed or languages have been added. The worst case is that a user gets a message App has been updated and needs to be reloaded. If your app uses history tokens (e.g. GWT places) then reloading the current place doesn't really hurt. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Current state of one .js file per module
Ok, I'll try to use separated servers for code server and server side. Regarding the monolithic .js, in GWT 1.6 it was impossible to debug in both Chrome and Firefox - they both crashed, and I always suspected that the js / sourcemap file were too big. Now with GWT 2.7 I can debug normally in Chrome (didn't try in Firefox yet). Still I guess it could be faster to debug using separated .js files. However, as this is no longer GWT's goal, ok. At least now debugging in Chrome is usable, and I no longer need that old version of Firefox 26 which still runs the classic dev mode. Em sexta-feira, 5 de dezembro de 2014 12h31min41s UTC-2, Jens escreveu: Separate compilation mentioned in your linked issue has been reworked into incremental per file compilation what you have now with GWT 2.7. The benefit is that people do not have to refactor their applications into multiple modules to get the benefit of faster recompiles in SDM. Regarding CodeServer restarts: With current GWT master branch, a restart of the CodeServer reuses the caches from the last compile which reduces the startup time of CodeServer significantly. Keep in mind that you do not have to use the DevMode class to start the embedded Jetty + Code Server process. You can also split these processes so you do not have to restart SDM CodeServer if you do a server side change. DevMode -noserver or launching CodeServer directly only starts the SDM code server. Then you can provide your own application server or actually start DevMode -nosuperdevmode which does start classic DevMode but also the embedded Jetty for your server side code. I rarely restart CodeServer during the work day. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Current state of one .js file per module
Hi. I created an issue several months ago - https://code.google.com/p/google-web-toolkit/issues/detail?id=8581[1] to split up generated .js. The answer was that a .js file, with its corresponding source map, would be generated per module. I'm analyzing now (with GWT 2.7.0) the output, and I still have 1 single monolithic, .js file and a single source map. Has this subject been aborted, postponed, or just not enabled by default? My project is big. It would be great if the files were split per module, as commented in the issue. I'd love to improve this, and reduce the timings on it. Specially between runs - sometimes small incompatible debug changes in server side forces a restart - and a new compilation. In this case, the reload button doesn't help, as the JVM is inconsistent anyway. Just for the record, here's the compilation log for the project (the real module was changed to package.Project). GET /recompile/project Job package.Project_1_0 starting job: package.Project_1_0 binding: user.agent=safari Compiling module package.Project Unification traversed 99049 fields and methods and 8257 types. 8223 are considered part of the current module and 8223 had all of their fields and methods traversed. Compiling 1 permutation Compiling permutation 0... Linking per-type JS with 8207 new types. prelink JS size = 21670288 prelink sourcemap = 21670288 bytes and 461483 lines postlink JS size = 21503531 postlink sourcemap = 21503531 bytes and 458742 lines Source Maps Enabled Compile of permutations succeeded Compilation succeeded -- 87,370s Linking into /tmp/gwt-codeserver-6688054585701610251.tmp/package.Project/compile-2/war/project; Writing extras to /tmp/gwt-codeserver-6688054585701610251.tmp/package.Project/compile-2/extras/project Link succeeded Linking succeeded -- 2,417s 90,304s total -- Compile completed [1] https://code.google.com/p/google-web-toolkit/issues/detail?id=8581 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: add mobile version to existing GWT app?
ok, but this leads me to the question, why we don't use REST/JSON right from the beginning? Isn't it a potential option for nearly any web application today to be complemented by a mobile version some day? I work in a large project which started in 2008, but was not full time back then, and only about, say 2011 got real priority. We started with the just released GWT 1.5, and there was not too many things to choose as today. Now we have a mobile app, and we have 2 entry point servlets: one to handle GWT RPC, and another one which exposes services in a rpc-like with json (not REST, as we don't want to maintain 2 APIs - it is just mirrored using Jackson). Not to say that we have A LOT of generated code to handle RPC. The current total size of our app is 3.3MB, where 6.4MB is for generated code for RPC (according to the compile report). Of course we use code splitting, but we're currently struggling on reducing the sizes. Currently, we have 975KB of initial download, 370KB of leftover and 9 split points (432KB max). If I'd start the project today, I'd just use plain REST / JSON for both the desktop and mobile versions. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: add mobile version to existing GWT app?
ok, but this leads me to the question, why we don't use REST/JSON right from the beginning? At the beginning of a project you usually know what you want to do. So if you want native clients for different platforms then you will start with some sort of REST/JSON or protobuff/thrift/... backend. When we started the current development, nobody cared about mobile apps or mobile versions of websites. Of course mobile today is the norm. But who knows what other device factor we'll have to support in some years from now? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Using SuperDevMode with code splitting
Well, I hope this will be sorted out, because debugging on a monolithic code of hundreds of thousands lines of code simply doesn't work - the browser hangs as expected. There's the following statement on http://www.gwtproject.org/articles/superdevmode.html : Currently, Super Dev Mode doesn't work on some very large GWT apps where classic Dev Mode works. This is probably because of the generated JS code size, but I'm sure this will be worked out. Otherwise, GWT will die in the short-mid term, because browser plugin based debugging is mostly dead (already in FF, soon in Chrome). Luis Fernando Planella Gonzalez Em 18-02-2014 04:57, Klemens Schrage escreveu: Maybe there are technical reasons for this since trying to use SourceMaps with CodeSplitting in a production environment gave me debugging problems (see https://groups.google.com/forum/#!topic/google-web-toolkit/kUpx5pOkqJs https://groups.google.com/forum/#%21topic/google-web-toolkit/kUpx5pOkqJs). -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/dFyODLo7QMo/unsubscribe. To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Using SuperDevMode with code splitting
I've reported
https://code.google.com/p/google-web-toolkit/issues/detail?id=8581
regarding this.
It is very important for large projects to work with SuperDevMode.
So, if anyone has the same problem, please, start the issue.
Best regards, Luis
Em 15-02-2014 10:53, Thomas Broyer escreveu:
On Friday, February 14, 2014 8:50:22 PM UTC+1, Luis Fernando Planella
Gonzalez wrote:
Well, after patching CompilerOptionsImpl in gwt-codeserver.jar to
return true in isRunAsyncEnabled(), the code server started
splitting the code, but source maps were only generated for the
initial fragment.
I don't know the internals, but shouldn't be terribly hard to have
the source maps for each split point, right? Or isn't it at all
supported by the compiler?
Compiling using -saveSource -saveSourceOutput dir together
with set-property name=compiler.useSourceMaps value=true /
and set-configuration-property name=includeSourceMapUrl
value=true / correctly saves all sources in the output dir and
sets the source map comments on each script...
Also, the CompilerOptionsImpl has this:
@Override
public boolean shouldSaveSource() {
return false; // handling this a different way
}
This different way is explicitly not handling the runAsync case.
Is there a strong reason for this?
SuperDevMode loads the source code right form its classpath (the same
way as when it compiles it) when sending it to the browser (see
SourceHandler and ModuleState).
That said, copying the sources would
solve https://code.google.com/p/google-web-toolkit/issues/detail?id=7615
(but saveSource has only been added recently, and I suspect
SuperDevMode just hasn't caught up yet)
--
You received this message because you are subscribed to a topic in the
Google Groups Google Web Toolkit group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/dFyODLo7QMo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups Google
Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Using SuperDevMode with code splitting
Hi. I'm recently attempting to use SuperDevMode, but our project is quite large, and the generated compiled .js has ~12MB. Chrome struggles (and hangs) when attempting to download source maps, making the whole debugging unpractical. Without SuperDevMode, we use code splitting, and the fragments are much more manageable. But SuperDevMode always compiles the application to a single .js file. Is it possible to use code splitting with SuperDevMode? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: Using SuperDevMode with code splitting
Well, after patching CompilerOptionsImpl in gwt-codeserver.jar to return
true in isRunAsyncEnabled(), the code server started splitting the code,
but source maps were only generated for the initial fragment.
I don't know the internals, but shouldn't be terribly hard to have the
source maps for each split point, right? Or isn't it at all supported by
the compiler?
Compiling using -saveSource -saveSourceOutput dir together with
set-property name=compiler.useSourceMaps value=true / and
set-configuration-property name=includeSourceMapUrl value=true /
correctly saves all sources in the output dir and sets the source map
comments on each script...
Also, the CompilerOptionsImpl has this:
@Override
public boolean shouldSaveSource() {
return false; // handling this a different way
}
This different way is explicitly not handling the runAsync case.
Is there a strong reason for this?
Thanks in advance.
Em sexta-feira, 14 de fevereiro de 2014 15h55min02s UTC-2, Luis Fernando
Planella Gonzalez escreveu:
Hi.
I'm recently attempting to use SuperDevMode, but our project is quite
large, and the generated compiled .js has ~12MB.
Chrome struggles (and hangs) when attempting to download source maps,
making the whole debugging unpractical.
Without SuperDevMode, we use code splitting, and the fragments are much
more manageable.
But SuperDevMode always compiles the application to a single .js file.
Is it possible to use code splitting with SuperDevMode?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Re: How to implement hashCode() and equals() for a point in 2D-space (x,y) in GWT?
Anyone has a better idea?
public boolean equals(Object obj) {
if (!(obj instanceof Point)) {
return false;
}
Point p = (Point) obj;
return fX == p.fY fY == p.fY;
}
public int hashCode() {
return (int) (pX + pY);
}
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: style of FileUpload widget
This has nothing to do with GWT. Inputs of type file cannot be styled using normal CSS. This has been an issue for years, and I don't know if it will ever have a standard solution. However, there are some obscure techniques, like this one: http://www.quirksmode.org/dom/inputfile.html On 3 mar, 09:09, Mathieu mathieu.cras...@gmail.com wrote: Hi I have to develop an application with GWT and UI Binder in Eclipse. I have to apply the Model View Presenter technic. I want to apply a special style to all the buttons of my application. Here comes the problem, I can't do that with the fileupload component. I tried different way to restyle the component (for instance just CSS), but there is nothing to do, I can't change its style. I also tried the method describe in several post that consists in hidding the fileupload component in the page, and redirect the events of other widget to our fileupload component. But this method doesn't work in firefox because the calls to javascript click method are blocked. So, if someone has a solution to cleanly resolv this problem ... thanks -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: style of FileUpload widget
I have implemented something like this in my own app, but can't post
the GWT code.
However, here is the HTML sketch I reproduced in GWT with widgets:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html
head
style type=text/css
!--
.uploadContainer {
bottom: 0px;
overflow: hidden;
position: absolute;
right: 0px;
top: 0px;
left: 0px;
}
.upload {
filter:alpha(opacity: 0);
opacity: 0;
z-index: 1;
position: absolute;
right: 0px;
top: 0px;
bottom: 0px;
cursor: pointer;
cursor: hand;
}
--
/style
/head
body
form
table cellpadding=0 cellspacing=0
tr
td align=right
div style=position:relative
button class=uploadButton type=button
id=uploadButtonABCDE/button
div class=uploadContainer
input type=file class=upload
onchange=getElementById('selectedFile').innerHTML = this.value/
/div
/div
/td
td id=selectedFile/td
/tr
/table
/form
/body
/html
On 3 mar, 13:08, Mathieu mathieu.cras...@gmail.com wrote:
thanks for your answer
I already did this technique but the fact is my browse button has 2
different styles switched when the mouse is over it. So with this
technique, the over mouseevent can't be use with the browse button
which is under the fileupload widget even if it's invisible :/
Maybe someone will have an idea to figure it out with this solution or
another, but anyway, thanks for your time, I appreciate.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Referencing deprecated class warning stack
I've got the same type of exception with same environment. Is there something that we missed? Yes, you missed the thread which is already discussing it ;) http://groups.google.com/group/google-web-toolkit/browse_thread/thread/cbf566637f03496a/a676bf46bb463f94?#a676bf46bb463f94 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deprecation warning in all RPCs dealing with collections on GWT 2.0 RC2
Could you add a bug to the GWT issue trackerhttp://code.google.com/p/google-web-toolkit/issues/list ? Done: http://code.google.com/p/google-web-toolkit/issues/detail?id=4438 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deprecated XXXListenerCollection warnings when migrating to GWT 2.0
I had already posted both the problem and the answer at http://groups.google.com/group/google-web-toolkit/browse_thread/thread/cbf566637f03496a Anyway, to see the real problem, compile with log level = debug and with the -compileReport option. You will see several files *.rpc.log. Those will contain why those classes were included. But, as I said in the other post, to me it seems a bug in the GWT compiler... On 19 dez, 06:38, Al Murauski a.murau...@gmail.com wrote: Absolutely the same problem after migrating to 2.0. On 19 дек, 00:57, Raziel raziel...@gmail.com wrote: Hi, I'm migrating my application from GWT 1.7 to GWT 2.0, and everything seems ok except for the warning below every time I compile: ] Adding '69' new generated units ] Validating newly compiled units ] [WARN] Warnings in 'generated:// 3DE2D57126EAE7405EEA01A75D45584C/com/appiancorp/gwt/appbuilder/client/ services/ApplicationRPCS eSerializer.java' ] [WARN] Line 286: Referencing deprecated class 'com.google.gwt.user.client.ui.ChangeListenerCollection' ] [WARN] Line 291: Referencing deprecated class 'com.google.gwt.user.client.ui.ClickListenerCollection' ] [WARN] Line 296: Referencing deprecated class 'com.google.gwt.user.client.ui.FocusListenerCollection' ] [WARN] Line 301: Referencing deprecated class 'com.google.gwt.user.client.ui.FormHandlerCollection' ] [WARN] Line 306: Referencing deprecated class 'com.google.gwt.user.client.ui.KeyboardListenerCollection' ] [WARN] Line 311: Referencing deprecated class 'com.google.gwt.user.client.ui.LoadListenerCollection' ] [WARN] Line 316: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseListenerCollection' ] [WARN] Line 321: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseWheelListenerCollection' ] [WARN] Line 326: Referencing deprecated class 'com.google.gwt.user.client.ui.PopupListenerCollection' ] [WARN] Line 331: Referencing deprecated class 'com.google.gwt.user.client.ui.ScrollListenerCollection' ] [WARN] Line 336: Referencing deprecated class 'com.google.gwt.user.client.ui.TabListenerCollection' ] [WARN] Line 341: Referencing deprecated class 'com.google.gwt.user.client.ui.TableListenerCollection' ] [WARN] Line 346: Referencing deprecated class 'com.google.gwt.user.client.ui.TreeListenerCollection' ] See snapshot: C:\DOCUME~1\RAZIEL~1.ALV\LOCALS~1\Temp \ApplicationRPCService_TypeSerializer4633447028131908703.java I don't understand why in the world I'm getting that since my code never defines signature related to any of those classes. Any idea? Thanks -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Limiting serializable types in RPC
Is there a way (it would be nice if there were one) to exclude types from RPC? Here's the concrete use case: In our project, the RemoteService interfaces are defined in a separate project as the web layer. And all methods / parameters use the Java best practices: always reference collections by it's interface. However, having a method to return CollectionString, for example, generates code to handle Vector, ArrayList, LinkedList, HashSet, LinkedHashSet... As interfaces are in a separated project, and it would be messy and make maintenance harder to change all interfaces to a given implementation... If I know I ALWAYS return ArrayLists or HashSets, is there a way to blacklist other types so code to handle all other types wouldn't get in our generated javascript? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deprecation warning in all RPCs dealing with collections on GWT 2.0 RC2
This issue is still present on GWT 2.0 final. I've made some tests: creating a new GWT project with Collections in RPC methods don't result in such code being inserted in the generated JavaScript. The point is: our project is quite huge, but I can confirm that there are no occurrences of any of the ListenerCollections mentioned. Compiling with -compileReport shows as only references for those collections the RPC generated TypeSerializers and FieldSerializers. Could someone, please, explain how to get rid of those unwanted (and unused) collections in the generated code? PS: I've read some time ago that all this deprecated code would be removed in GWT 2. It's even in the source code that it would be removed. Why it wasn't?!? If it's for people using the old event listeners, I can assure that I've migrated from GWT 1.5 to 1.7 in 1,5 days. When I first replaced Listeners by Handlers I had 600+ compilation errors. Just changed the inner classes and everything worked. And better. Not to count having to rearrange the app to use the war directory. So I think this is no excuse for keeping deprecated code, as I think that 99% of the GWT users are working in a code base the same size or smaller than ours. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT 2.0 - Eclipse - Need to Recompile after every change
Make sure you have ?gwt.codesvr=127.0.1.1:9997 at the end of the URL in the browser. That's what makes it use development mode. Otherwise, it will just be the plain old web mode (now called production mode). On 11 dez, 10:46, ziggystardust camke...@gmail.com wrote: Been using GWT / App Engine and the Eclipse plugin for some time now and just recently upgraded to 2.0. I reinstalled Eclipse (3.5), installed the plugin and the sdks. Setup the example StockWatcher app and everything runs fine. In dev mode however I have to recompile whenever i make a change in order for it to be effective. Tried reload and restarting the browser (IE and Chrome), tried restarting the server but no joy. Any ideas appreciated. Thanks. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deprecation warning in all RPCs dealing with collections on GWT 2.0 RC2
Just found the answer, and luckily in my case it was simple to solve I have a subtype of ListT called PageImplT, which had another ListT containing the page items, plus the total count. Then (and I think is a problem in GWT compiler), the compiler resolves FocusListenerCollection, which extends ArrayListFocusListener to be a subclass of ListT. As a result, ALL occurrences of Collection of anything in any RPC method, by having PageImpl as a subclass of collection, had added those ListenerCollections as possible result types, generated code to handle them (50k in my case) and issued the warnings. The solution (in better words: hack) was to change PageImpl to not have a List of page items, but a LinkedList (it then converts the receiving list into a LinkedList, which is even a penalty in my case). As no ListenerCollection extends LinkedList, the problem is gone. Ah, I also had an RPC which result type was ListListString. The same problem. As it was just for testing, I changed it to ListString[] . But I'd really want to hear from a GWT dev if this is not a bug in the compiler... On 11 dez, 13:04, Ashar Lohmar asharloh...@gmail.com wrote: Hi I'm having the same kind of problem. in my app i use some libraries/object written in Java 1.4 style the objects implement Serializable but contain Lists or Maps which are declare without parameters i mean List instead of ListE, as the Java 1.4 requires and some RPC classes return this kind of objects but on Gwt-compiling I endup with a lot of code referencing all kinds of Listeners and stuffs that are unrelated to the RPC service. Basically the messages appear because the Listeners are deprecated,but what are they doing there in the first place ? hope someone will clear this up On Dec 8, 7:24 pm, Luis Fernando Planella Gonzalez lfpg@gmail.com wrote: Hi. We're using GWT 1.7 and I'm starting to experiment with 2.0 RC2 to evaluate GWT.runAsync(). However, now as I compile the app, I get warning for deprecations in all RPC methods which return collections. I guess it's because the result is declared as java.util.Collection, and the deprecated com.google.gwt.user.client.ui.*ListenerCollection classes extends ArrayList, making even the alternative to change the result of RPC methods to ArrayList instead of Collection don't work. The log is something like this, multiple times: [WARN] Warnings in 'generated:// 8D0B12EA4B123D9B133384111C9A7E38/nl/strohalm/cyclos/client/app/users/ images/UserImageRemoteService_TypeSerializer.java' [WARN] Line 50: Referencing deprecated class 'com.google.gwt.user.client.ui.ChangeListenerCollection' [WARN] Line 55: Referencing deprecated class 'com.google.gwt.user.client.ui.ClickListenerCollection' [WARN] Line 60: Referencing deprecated class 'com.google.gwt.user.client.ui.FocusListenerCollection' [WARN] Line 65: Referencing deprecated class 'com.google.gwt.user.client.ui.FormHandlerCollection' [WARN] Line 70: Referencing deprecated class 'com.google.gwt.user.client.ui.KeyboardListenerCollection' [WARN] Line 75: Referencing deprecated class 'com.google.gwt.user.client.ui.LoadListenerCollection' [WARN] Line 80: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseListenerCollection' [WARN] Line 85: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseWheelListenerCollection' [WARN] Line 90: Referencing deprecated class 'com.google.gwt.user.client.ui.PopupListenerCollection' [WARN] Line 95: Referencing deprecated class 'com.google.gwt.user.client.ui.ScrollListenerCollection' [WARN] Line 100: Referencing deprecated class 'com.google.gwt.user.client.ui.TabListenerCollection' [WARN] Line 105: Referencing deprecated class 'com.google.gwt.user.client.ui.TableListenerCollection' [WARN] Line 110: Referencing deprecated class 'com.google.gwt.user.client.ui.TreeListenerCollection' See snapshot: /tmp/ UserImageRemoteService_TypeSerializer2951604978153994580.java Is there a way to remove those classes from being handled in RPC? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deprecation warning in all RPCs dealing with collections on GWT 2.0 RC2
In fact, there is a very easy way to reproduce it: Just create a RPC method which returns ListListString. You'll see references for those deprecated collections. On 11 dez, 17:39, Luis Fernando Planella Gonzalez lfpg@gmail.com wrote: Just found the answer, and luckily in my case it was simple to solve I have a subtype of ListT called PageImplT, which had another ListT containing the page items, plus the total count. Then (and I think is a problem in GWT compiler), the compiler resolves FocusListenerCollection, which extends ArrayListFocusListener to be a subclass of ListT. As a result, ALL occurrences of Collection of anything in any RPC method, by having PageImpl as a subclass of collection, had added those ListenerCollections as possible result types, generated code to handle them (50k in my case) and issued the warnings. The solution (in better words: hack) was to change PageImpl to not have a List of page items, but a LinkedList (it then converts the receiving list into a LinkedList, which is even a penalty in my case). As no ListenerCollection extends LinkedList, the problem is gone. Ah, I also had an RPC which result type was ListListString. The same problem. As it was just for testing, I changed it to ListString[] . But I'd really want to hear from a GWT dev if this is not a bug in the compiler... On 11 dez, 13:04, Ashar Lohmar asharloh...@gmail.com wrote: Hi I'm having the same kind of problem. in my app i use some libraries/object written in Java 1.4 style the objects implement Serializable but contain Lists or Maps which are declare without parameters i mean List instead of ListE, as the Java 1.4 requires and some RPC classes return this kind of objects but on Gwt-compiling I endup with a lot of code referencing all kinds of Listeners and stuffs that are unrelated to the RPC service. Basically the messages appear because the Listeners are deprecated,but what are they doing there in the first place ? hope someone will clear this up On Dec 8, 7:24 pm, Luis Fernando Planella Gonzalez lfpg@gmail.com wrote: Hi. We're using GWT 1.7 and I'm starting to experiment with 2.0 RC2 to evaluate GWT.runAsync(). However, now as I compile the app, I get warning for deprecations in all RPC methods which return collections. I guess it's because the result is declared as java.util.Collection, and the deprecated com.google.gwt.user.client.ui.*ListenerCollection classes extends ArrayList, making even the alternative to change the result of RPC methods to ArrayList instead of Collection don't work. The log is something like this, multiple times: [WARN] Warnings in 'generated:// 8D0B12EA4B123D9B133384111C9A7E38/nl/strohalm/cyclos/client/app/users/ images/UserImageRemoteService_TypeSerializer.java' [WARN] Line 50: Referencing deprecated class 'com.google.gwt.user.client.ui.ChangeListenerCollection' [WARN] Line 55: Referencing deprecated class 'com.google.gwt.user.client.ui.ClickListenerCollection' [WARN] Line 60: Referencing deprecated class 'com.google.gwt.user.client.ui.FocusListenerCollection' [WARN] Line 65: Referencing deprecated class 'com.google.gwt.user.client.ui.FormHandlerCollection' [WARN] Line 70: Referencing deprecated class 'com.google.gwt.user.client.ui.KeyboardListenerCollection' [WARN] Line 75: Referencing deprecated class 'com.google.gwt.user.client.ui.LoadListenerCollection' [WARN] Line 80: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseListenerCollection' [WARN] Line 85: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseWheelListenerCollection' [WARN] Line 90: Referencing deprecated class 'com.google.gwt.user.client.ui.PopupListenerCollection' [WARN] Line 95: Referencing deprecated class 'com.google.gwt.user.client.ui.ScrollListenerCollection' [WARN] Line 100: Referencing deprecated class 'com.google.gwt.user.client.ui.TabListenerCollection' [WARN] Line 105: Referencing deprecated class 'com.google.gwt.user.client.ui.TableListenerCollection' [WARN] Line 110: Referencing deprecated class 'com.google.gwt.user.client.ui.TreeListenerCollection' See snapshot: /tmp/ UserImageRemoteService_TypeSerializer2951604978153994580.java Is there a way to remove those classes from being handled in RPC? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: how large of your GWT compiled code? My one is 850K
Sorry for taking so long to answer, but I haven't seen your post before. We haven't yet done any larger performance test, but it is very acceptable. Yesterday, in a first no-brainer attempt of GWT.runAsync(), I've managed to get a 650K initial download and then a separate file per module (for now, modules varies from few K to 180K). I'll still try to reduce both the initial download and the modules. It does takes more time to compile now. That's an issue to me as I can't use the built-in server: we use EJB, so there's an external server. Whenever anything changes in RPC (params, methods, even classes) we need to recompile :-/ I still didn't implement gzip compression, but hope things can get much better... Ah, about IE6: as our app is targeted to late 2010, we won't support IE6 \o/ -- Luis Fernando Planella Gonzalez On 16 nov, 12:19, Bakul bakul.ku...@gmail.com wrote: Hi, Our app, 50 -55 % done so far, for one browser is nearly 1.6 MB without gzip. And it has nearly 70 -80 RPC calls. Luis, Question for you: As you said your app is 2.1 MB of obfuscated, how is the preformance and does it has any issue? Question to all: What is the max size that of GWT one module that a browser can handle without any issue, specially IE 6, in our case :-( ? Thanks, Bakul. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Deprecation warning in all RPCs dealing with collections on GWT 2.0 RC2
Hi. We're using GWT 1.7 and I'm starting to experiment with 2.0 RC2 to evaluate GWT.runAsync(). However, now as I compile the app, I get warning for deprecations in all RPC methods which return collections. I guess it's because the result is declared as java.util.Collection, and the deprecated com.google.gwt.user.client.ui.*ListenerCollection classes extends ArrayList, making even the alternative to change the result of RPC methods to ArrayList instead of Collection don't work. The log is something like this, multiple times: [WARN] Warnings in 'generated:// 8D0B12EA4B123D9B133384111C9A7E38/nl/strohalm/cyclos/client/app/users/ images/UserImageRemoteService_TypeSerializer.java' [WARN] Line 50: Referencing deprecated class 'com.google.gwt.user.client.ui.ChangeListenerCollection' [WARN] Line 55: Referencing deprecated class 'com.google.gwt.user.client.ui.ClickListenerCollection' [WARN] Line 60: Referencing deprecated class 'com.google.gwt.user.client.ui.FocusListenerCollection' [WARN] Line 65: Referencing deprecated class 'com.google.gwt.user.client.ui.FormHandlerCollection' [WARN] Line 70: Referencing deprecated class 'com.google.gwt.user.client.ui.KeyboardListenerCollection' [WARN] Line 75: Referencing deprecated class 'com.google.gwt.user.client.ui.LoadListenerCollection' [WARN] Line 80: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseListenerCollection' [WARN] Line 85: Referencing deprecated class 'com.google.gwt.user.client.ui.MouseWheelListenerCollection' [WARN] Line 90: Referencing deprecated class 'com.google.gwt.user.client.ui.PopupListenerCollection' [WARN] Line 95: Referencing deprecated class 'com.google.gwt.user.client.ui.ScrollListenerCollection' [WARN] Line 100: Referencing deprecated class 'com.google.gwt.user.client.ui.TabListenerCollection' [WARN] Line 105: Referencing deprecated class 'com.google.gwt.user.client.ui.TableListenerCollection' [WARN] Line 110: Referencing deprecated class 'com.google.gwt.user.client.ui.TreeListenerCollection' See snapshot: /tmp/ UserImageRemoteService_TypeSerializer2951604978153994580.java Is there a way to remove those classes from being handled in RPC? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
RichTextArea problem when applying format under IE
Hi. I'm using custom widgets as a RichTextArea toolbar, and those with a dropdown selection (fore and back color, font and font size) use a div in a PopupPanel to show the options. Everything is ok in Firefox and Opera, but Internet Explorer seems to loose the cursor position when the user clicks one of those buttons, and when an option is selected, the format is applied in the beginning of the RichTextArea, not on the expected position. This can be reproduced in the Showcase as well: select a text portion, click somewhere outside the editor, then select a font color, for example. That style is applied in the beginning of the text. I think it works in the Showcase when selecting directly a format select box because it's a native component... Anyone has any idea on how to work around this? - Luis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Bug getting the text background color in RichTextArea under Mozilla
HI. I've raised http://code.google.com/p/google-web-toolkit/issues/detail?id=3262 which records that RichTextAreaImplMozilla overrides the setBackColor(), as it uses 'HiliteColor', not 'BackColor' command, but it does not overrides getBackColor() with the same logic, making it impossible to query it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
