Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT
I think Alain's use case is a legit one, and the SmartGWT product probably also lives in that world to an extent - let the user write Java that mostly interacts with JS libraries, and let them worry about which browser is running, but compile the code to run anywhere. I can't speak to their 'older browser' need though - Alain, what do you guys target? On Thu, Jul 17, 2014 at 6:52 PM, 'Brian Slesinsky' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: It would make sense in principle but we don't know anyone who wants to target older browsers without also using permutations. On Tue, Jul 15, 2014 at 3:55 AM, Jens jens.nehlme...@gmail.com wrote: I believe Google builds applications that use Elemental and/or JsInterop, so they don't use c.g.g.dom.DOM or any other thing that inherits UserAgent. Goktug also pointed out earlier in this thread cross-compiled apps where the UI is built with Closure Library. I suspect this might be the case of Google Drive (Spreadsheets) where GWT is only used to compile to JS those bits of Java that are shared with the server, Android app and iOS app (through J2ObjC); from what I understood, in Spreadsheets that would be the code necessary to parse and evaluate formulas. Thanks for the examples. Such cross compiled apps probably doesn't have the concept of permutations but they maybe also want to support older browsers. Wouldn't it make sense then to have something like Core.gwt.xml which is strictly modern, and CoreWithLegacySupport.gwt.xml which inherits Core and introduces runtime feature checks here and there? That way such apps don't have to pull in UserAgent at all and its probably more straight forward than saying: If you need legacy support then inherit core, useragent and possibly collapse all properties if you want a single permutation. Also GWT would have the control how it provides legacy support and far in the future if GWT only has a modern and a legacy permutation then Core could provide the modern permutation while CoreWithLegacySupport introduces the legacy permutation and UserAgent maps all the user agents to modern or legacy. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 218.248.6165 niloc...@gmail.com -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMwudpoUF9nQdaxaHKDanthq470nioODFYCaUZAbf%3Dnt%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT
Sorry for the delay in getting back to you (and to my reviews, got at least one up to date now), finally catching up after a few days off. I guess I was looking for We want to use Object.create in Core in your initial email. If we also wanted any/all of the features I had listed (fast byte[]/int[]/double[] for everyone? rpc-over-ws? cors?), dropping ie9 from Core might have also made sense. I'm not actually encouraging cutting IE9 (or 8), esp from User, but if we want to move some emulation code off to UserAgent or User, letting go of IE9 may make sense. My email was written from the perspective of huh, Goktug wants to drop IE8 because it will make *something* easier - won't also dropping IE9 make more something even more easier?. With the caveat that all you are interested in is Object.create, targeting only IE8 makes sense. On Tuesday, July 1, 2014 12:02:50 AM UTC-5, Goktug Gokdogan wrote: On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth nilo...@gmail.com javascript: wrote: Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js). A cross-compiled app is a good example that doesn't need User where you can, for example, use closure to develop the UI. I specifically pointed IE8 as it is the only supported browser missing Object.create functionality and such apps that just depends on java.emul are paying the price of IE8. On the other hand by just inheriting useragent.UserAgent (not necessarily the User) an app can target older browsers. Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/). If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper. Can you be more specific? On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote: We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations. Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core). Let me know if you have any concerns. - Goktug -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8e78df45-4d71-4dcf-9fea-52d32fc58d65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Future of Renderable and PotentialElement?
PotentialElement seems to be one of those ghost features that was never
finished, or at least never correctly documented, so might as well be half
done:
EXPERIMENTAL and subject to change. Do not use this in production code.
We've never used it, and I've only encouraged people to stay away from it,
since, well, we aren't supposed to use it in production code.
There are only a handful of places that use PotentialElement - a Composite
has a 'resolve' step, DOM does some resolution as well, UiObject just has a
ton of asserts, and then of course RenderablePanel, EXPERIMENTAL and
subject to change. Do not use this in production code.. Then we get this
tidbit:
This class is a stepping in our transition to the Renderable strategy.
Eventually this functionality should be merged into {@link HTMLPanel}.
Related classes seem to include IsRenderable:
This interface is very experimental and in active development, so the
exact API is likely to change. Very likely. In fact, it will definitely
change. You've been warned.
Hard to argue with that. The snark is kinda fun, but we should know better
for production code.
/**
* @see #render(RendearbleStamper, SafeHtmlBuilder)
* TODO(rdcastro): Remove this once UiBinder doesn't rely on it anymore.
*/
SafeHtml render(RenderableStamper stamper);
I'm assuming UiBinder still relies on it.
// TODO(rdcastro): use the render() call that receives the
SafeHtmlBuilder
String elementHtml =
fieldManager.convertFieldToGetter(childFieldWriter.getName()) + .render(
+ fieldManager.convertFieldToGetter(stamper) + );
Yep. Also looks like Composite and RenderablePanel use it too.
From an outsider's perspective, this is not only unfinished code, but
probably abandoned since it has been left unfinished for so long. If it
isn't going to be finished/maintained, it should be deprecated, wait a
version and remove it, otherwise it should be 'completed'. Another option
would be to factor it out to its own jar so that it doesn't appear to be an
integral part of User... but the hooks in DOM.java will make that hard, and
the 'only com.google.gwt code can write uibinder parsers' make this even
tougher.
On Sun, Jul 6, 2014 at 10:25 PM, 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
On Sun, Jul 6, 2014 at 8:05 PM, Stephen Haberman
stephen.haber...@gmail.com wrote:
Even Orkut closing the doors, it doesn't mean their code is going away
anytime soon :)
You're killing me, Goktug. The backwards compatibility knife had
already pierced my heart, and this just shimmied it around a bit. :-)
The point was more about Orkut announcement doesn't change anything and
cannot effect the decision from our perspective; as long as the system is
running we need to take care of it.
I had to refresh on memory on PotentialElement, but it looks virtual
DOM-ish; making fake elements that are really pure JS objects, and then
later converting them into real DOM objects only as-needed. I believe
it sped up the first page load of Orkut by ...15%? or so.
I also vaguely recall that, AFAIU, the pipe dream was to have the
entire initial DOM render be one huge .innerHTML=blah, since IE
really liked that. But making strings that big hurts the GC such that
(AFAIK) it's a wash in modern browsers to just making DOM elements
directly anyway.
Speaking of PotentialElement, looking at commits from around that time
frame, there is also a change from Ray Ryan that turned
useLazyWidgetBuilders = true, with a commit message of in prep for
deleting the old code.
Looks like that deleting never happened...can we do that now?
As with PotentialElement, I don't think useLazyWidgetBuilders had any
external design docs, discussion, etc., so I don't really know the
whole story on it. Or even little bits, other than I enjoy deleting old
code and will volunteer to do that if we can.
- Stephen
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/20140706220525.6ccc4472%40sh9
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2itF_dBO%3D8GpRmRgs0%3D2NfeBY1r%3Dhr2may347Hb9BQHg%40mail.gmail.com
[gwt-contrib] Re: Dropping IE8 support in useragent-less GWT
Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js). Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/). If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper. On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote: We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations. Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core). Let me know if you have any concerns. - Goktug -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] user tests fail to compile
I’m trying to bring https://gwt-review.googlesource.com/#/c/3361/ up to
date, and after rebasing and fixing a few whitespace nits I tried to run
the tests by they failed. Concerned that I had broken something I backed
off to current master, and ran tests again. First I did a clean dist-dev in
the root directory, then simply compiling user tests, I get a failure:
[colin@modo user (master)]$ ant clean compile.tests
Buildfile: /Users/colin/Documents/idea/gwt/user/build.xml
clean:
[delete] Deleting directory
/Users/colin/Documents/idea/gwt/build/out/user
compile.dev.tests:
compiler.standalone:
build.alldeps.jar:
compile:
-filter.props:
build:
compile.emma.if.enabled:
-compile.emma.if.enabled:
compile.tests:
[gwt.javac] Compiling 1 source file to
/Users/colin/Documents/idea/gwt/build/out/dev/bin-test
compile.emma.if.enabled:
-compile.emma.if.enabled:
compile.tests:
[mkdir] Created dir:
/Users/colin/Documents/idea/gwt/build/out/user/bin-test
[gwt.javac] Compiling 1514 source files to
/Users/colin/Documents/idea/gwt/build/out/user/bin-test
[gwt.javac]
/Users/colin/Documents/idea/gwt/user/test/com/google/gwt/dev/testdata/incrementalbuildsystem/super/com/google/gwt/dev/testdata/incrementalbuildsystem/ImmediateCompileFails.java:19:
error: duplicate class:
com.google.gwt.dev.testdata.incrementalbuildsystem.ImmediateCompileFails
[gwt.javac] public class ImmediateCompileFails {
[gwt.javac]^
[gwt.javac]
/Users/colin/Documents/idea/gwt/user/test/com/google/web/bindery/requestfactory/apt/RfValidatorTest.java:177:
error: cannot find symbol
[gwt.javac] rfValidator.setClientOnly(clientOnly);
[gwt.javac]^
[gwt.javac] symbol: method setClientOnly(boolean)
[gwt.javac] location: variable rfValidator of type RfValidator
[gwt.javac] Note: Some input files use or override a deprecated API.
[gwt.javac] Note: Recompile with -Xlint:deprecation for details.
[gwt.javac] Note: Some input files use unchecked or unsafe operations.
[gwt.javac] Note: Recompile with -Xlint:unchecked for details.
[gwt.javac] 2 errors
BUILD FAILED
/Users/colin/Documents/idea/gwt/user/build.xml:150: Compile failed; see the
compiler error output for details.
Total time: 15 seconds
Anyone else seeing this, or is it likely a local env issue? I’ve confirmed
that my tools/ dir is up to date, and I’m not sure what other local
configuration might be required just to compile tests.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0703af1b-e8bd-420d-9b6d-71dbbd281ce0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: user tests fail to compile
With some help from Jens Nehlmeier over in ##gwt, it looks like there are
two distinct issues preventing the build from passing presently The first
is that the class ImmediateCompileFails does in fact cause problems with
compiling - the simplest fix was to tell the compile.tests target to leave
off compiling any super sources:
diff --git a/user/build.xml b/user/build.xml
index 274f4ef..54fc17d 100755
--- a/user/build.xml
+++ b/user/build.xml
@@ -147,7 +147,7 @@
depends=compile.dev.tests, compile.emma.if.enabled
unless=compile.tests.complete
mkdir dir=${javac.junit.out}/
-gwt.javac srcdir=test excludes=com/google/gwt/langtest/**
destdir=${javac.junit.out}
+gwt.javac srcdir=test
excludes=com/google/gwt/langtest/**,**/super/**
destdir=${javac.junit.out}
classpath
pathelement location=${javac.out}/
pathelement location=${gwt.tools.lib}/junit/junit-4.8.2.jar/
The second issue is that the requestfactory-apt.jar in the GWT Tools SVN
repo appears to be out of date. Doing a dist-dev build and copying the
newly generated -apt over to my local SVN checkout seems to bring this back
into working order.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/79c83872-2dfc-4272-be9d-9b08845ace22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: SafeHtml on the server/vm
Ah ha! I dropped the ball in my testing, by supporting GWT 2.4+ instead of limiting to something more recent and manageable like 2.5.1+. Confirmed, SafeHtml etc is in gwt-servlet in recent GWT. Thanks for the sanity check Thomas. On Tuesday, June 10, 2014 3:43:48 AM UTC-5, Thomas Broyer wrote: On Tuesday, June 10, 2014 12:33:40 AM UTC+2, Colin Alworth wrote: Currently SafeHtml co live in gwt-user, though they are for the most part listed in a shared package, implying that a server can use them. However, gwt-user.jar also includes javax packages as well as hibernate, w3c, etc, so can't reasonably be imported to a server which already uses any of those packages (i.e. any servlet container). Is this an oversight in the publicly packaged GWT and is SafeHtml used by teams that package differently, or instead is this package not actually intended for server use, but instead just compile-time tasks where gwt-user is on the classpath like compiling or linking? I'm doing some work on a non-servlet server which hasn't so far seen concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy way to get server generated HTML from code that is shared with the client. This use case *appears* to be implied from the package name, but presently isn't possible for the majority of GWT backends. Ideas on why it is the way it is? Thoughts on how to make it available to the server (without giving it yet another jar a la requestfactory-server)? Interest in a contributed SafeHtmlTemplates implementation for JVM? SafeHtml *is* in gwt-servlet. In 2.5.1 and earlier it was missing the streamhtmlparser classes, but we've fixed this in 2.6 so it should work now (I must say I haven't tried it though) -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7f06ce36-64a7-441a-92eb-421b2889e5ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] SafeHtml on the server/vm
Currently SafeHtml co live in gwt-user, though they are for the most part listed in a shared package, implying that a server can use them. However, gwt-user.jar also includes javax packages as well as hibernate, w3c, etc, so can't reasonably be imported to a server which already uses any of those packages (i.e. any servlet container). Is this an oversight in the publicly packaged GWT and is SafeHtml used by teams that package differently, or instead is this package not actually intended for server use, but instead just compile-time tasks where gwt-user is on the classpath like compiling or linking? I'm doing some work on a non-servlet server which hasn't so far seen concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy way to get server generated HTML from code that is shared with the client. This use case *appears* to be implied from the package name, but presently isn't possible for the majority of GWT backends. Ideas on why it is the way it is? Thoughts on how to make it available to the server (without giving it yet another jar a la requestfactory-server)? Interest in a contributed SafeHtmlTemplates implementation for JVM? Thanks, Colin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f3f89edf-ce77-4975-a5c8-f33e7e0a1886%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SafeHtml on the server/vm
Like I said, its not a concern for me (no servlet, no hibernate, no flute), but for those who want to stick gwt-user.jar in a WEB-INF/lib/, it would be nice to not have to renamed it zwt-user.jar. My knee-jerk reaction is to put it in gwt-servlet (since other relatively new classes like AutoBeanFactorySource also made it in there) - does that seem like a reasonable step? On Mon, Jun 9, 2014 at 6:22 PM, John A. Tamplin j...@jaet.org wrote: On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth niloc...@gmail.com wrote: Currently SafeHtml co live in gwt-user, though they are for the most part listed in a shared package, implying that a server can use them. However, gwt-user.jar also includes javax packages as well as hibernate, w3c, etc, so can't reasonably be imported to a server which already uses any of those packages (i.e. any servlet container). Is this an oversight in the publicly packaged GWT and is SafeHtml used by teams that package differently, or instead is this package not actually intended for server use, but instead just compile-time tasks where gwt-user is on the classpath like compiling or linking? I'm doing some work on a non-servlet server which hasn't so far seen concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy way to get server generated HTML from code that is shared with the client. This use case *appears* to be implied from the package name, but presently isn't possible for the majority of GWT backends. Ideas on why it is the way it is? Thoughts on how to make it available to the server (without giving it yet another jar a la requestfactory-server)? Interest in a contributed SafeHtmlTemplates implementation for JVM? Yes, SafeHtml is intended to be usable on the server. There have been various discussions about splitting up gwt-user into parts for client-only, shared (and perhaps server-only), but that wasn't ever done. Mostly, putting gwt-user last on the classpath on your server won't cause any issues, though at least one JVM used to be unhappy with native methods without corresponding binaries. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 218.248.6165 niloc...@gmail.com -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzdu5cz3bjvWYW7%3DvUm%3D%3DfC0b83sg0%3Dbs7j%2BmTNDjFSeg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Officially deprecating Opera permutation
I've just opened https://gwt-review.googlesource.com/7780 to make it possible to specify a fallback for any/all useragents that don't match one of the built-in rules, via a rule like: set-property-fallback name=user.agent value=webkit/ This example rule treats any unknown useragent as if it were webkit, rather than the non-existent 'unknown' useragent, which subsequently tries to load undefined.cache.html, etc. This could also be used in conjunction with defining a user.agent value for unknown browsers and falling back to an existing one (like Thomas suggested), along with a possible error message, but that runs the risk of failing to match any CssResource @if rules, for example. This will of course create a huge amount of warnings in your application Could not find an exact match rule. Using 'closest' rule... when attempt to rebind things that cannot be matched to unknown and fall back to gecko1_8, etc. !-- Create new value, try and use ff details for it (most of the time) -- extend-property name=user.agent values=unknown fallback-value=gecko1_8 / !-- this line is not actually necessary unless you want to use a string other than 'unknown', and won't work before the above patch -- set-property-fallback name=user.agent value=unknown/ !-- 'most of the time' we want ff, except for a warning when the page boots. -- !-- To achieve that, we create a second entrypoint that extends the real one, but also displays a warning about this browser being unsupported -- replace-with class=pack.age.to.client.UnknownBrowserEntryPoint when-type-is class=pack.age.to.client.RealAppEntryPoint / /replace-with Thomas, were you suggesting a filter in GWT itself to let the server do this, or to have an 'UnknownUserAgentEntryPoint' built into GWT itself? On Saturday, May 10, 2014 5:27:37 PM UTC-5, Thomas Broyer wrote ...snip... That said, Google Groups and Google Flight Search fallback to the gecko1_8 permutation in Opera 12 (with a warning message that it might break), so we should probably make it possible at least (Google uses a server-side selection script based on the User-Agent request header, rather than the *.nocache.js using navigator.userAgent on the client-side) Would you mind opening an issue about it? Maybe there's a workaround though: it might be as easy as defining a unknown (the value returned by the property generator) value for the user.agent property that falls back to gecko1_8 (just like ie9 falls back to ie8): i.e. extend-property name=user.agent values=unknown fallback-value=gecko1_8 /; and then you could use deferred-binding specifically for that unknown value to display a warning message, and you could collapse unknown and gecko1_8 values into the same permutation. Worth a try IMO if you care about it. On Friday, May 9, 2014 8:14:55 PM UTC+2, Robert J. Carr wrote: This just burned me. Just curious why you couldn't have it load the file from firefox or webkit instead of just doing nothing? Better to deal with potential errors than to be a total non-starter. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/de99d642-710b-44c9-8439-11a108d8e840%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Officially deprecating Opera permutation
Sorry, that first line should say 'safari' (or any other valid user.agent value), not 'webkit'. Wishful thinking perhaps... set-property-fallback name=user.agent value=*safari*/ -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/92eace59-aa42-468c-823e-8c39dd82ff59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
This seems to be a pretty quiet discussion so far, with mostly Zied
responding to himself and Thomas’s one initial reply, but it is a holiday
weekend here in the US, so that might be contributing to the lack of
additional responses. I haven’t had the chance to even look at the initial
proposal until this morning, but at a glance, I agree that it would be an
interesting successor to uibinder or add-on to uibinder, but likely a poor
modification of uibinder. I’m going to completely ignore the security
aspect, as the ‘best practice’ is to ‘do it on the server’, and never ever
trust the client. If you try trusting the client, you are better of just
omitting the security to avoid any false sense of safety ;).
- UiBinder is totally declarative - if it had the feature to wire in
logical statements, we should equally have loop and conditional constructs.
- Not everyone uses UiBinder, not everything can be done with UiBinder -
use of this tool will be limited to users and use-cases that already are
good fits for uibinder. Anything that is @UiField(provided=true)/@UiFactory
may be ineligible (since they may be have some runtime decided type, so the
UiBinder generator can’t see their moving target of setters), any cells or
other non-uibinder-able ui components can’t work either.
- I don’t see a full proposal anywhere, but from the issue at
code.google.com it appears that the intention is to provide isAllowed and
isReadOnly, and these cases only at initial widget creation, based on a
String idPath, synchronously. Implications from here: All possible
permissions that the app might ever access need to be loaded preemptively,
and from that the server needs to know (and have sent) all possible paths
that the app might have, permissions can’t change without the app being
reloaded (either user gets errors from the server when permissions change
while the app is running, or whole app should be refreshed when any
permission change of current user, group, or other business logic changes),
and permissions are never data-dependent (no need to ever check if the user
‘owns’ the given object, etc).
- isAllowed is a bit of a terrifying prospect - either it is not being
rendered as the specified type (i.e. all @UiFields must be Object and
typed-checked at runtime), or they are left as null (and null checked for
any .add, .setWidget that uses them, any add/setter called *on* them, and
any {} reference made *to* them across all of uibinder internals). Again,
not very declarative, since the type assumptions that can be made by users
authoring the matching .java and .ui.xml need to assume that any of their
declared code in xml might just be ignored and not available in .java.
Were I doing this, I’d go in another direction - don’t try to rewrite
UiBinder into an imperative language, but instead make your own
non-declarative xml-widgets that cover the required cases. Support
conditions and looping, expect to call out to java (or better yet let java
call back in to note that a state change has happened in permissions), and
accept more data, such as the current model object, etc. No need to be
accommodating to UiBinder or non-UiBinder, since this is a new tool
entirely.
For fun, I made a aop-replacement tool, ostensibly for simple ui hints
about permissions for access to things. The goal wasn’t to demonstrate that
*all* AOP can be achieved with simpler constructs, but instead to show that
much if it can, much of the time, with very little code. This tool was
annotation based - define your own annotations and the logic that drives
them, stick them on fields in the view, and ask the rules to run when any
changes are made. For example, this annotation means ‘call
.setVisible(currentUser.group == foo) on any widget with
@OnlyVisibleTo(foo) on it. This is triggered by extending an interface and
keying off of the view type and the model type - the resulting object has a
‘apply’ method that lets it take the view and the model, and applies the
various rules declared in the view.
Annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/Sample.java?at=master
Sample that uses the annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/OnlyVisibleTo.java?at=master
I’m not proposing that this is the only way to solve this, but it is
compatible with regular java views or UiBinder (just stick the annotations
next to the @UiField). I also am not pushing this as a way to solve this
sort of problem out of concerns for developers confusing the concept of
hiding or disabling a widget with actual authorization, but am instead
trying to move this toward a sort of binding tool, but for properties other
than what editors normally work with (i.e. getter/setter against
Feature Request: UIBinder Page Viewer
Create a Viewer that will give you a static look at how the currently open UIBinder page you are working on would look in a browser. I find this would be useful because if you are working on a page that you have to navigate through a lot of stuff to get to on your website just to look at your changes and how they appear is really time consuming. It would be easier to view the page in eclipse or intellij while you are editing it. -- 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.
[gwt-contrib] Re: Can we move the code to GitHub?
Only note to add here is that the AngularJS project does require a CLA also (see https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#cla) - it looks like they either have a bot which complains about missing CLAs on file (and so some associated between username and real name), or a very diligent user with a form that gets copy/pasted a lot. But, as Thomas noted, this can't stop a developer from accidently merging code which the contributor may not have the rights to merge. Okay, one more though: Remember the mess between Google and Oracle over Android emulating the JRE, specifically the part about possibly reusing some without permission? GWT has the same basic issue, the CLA isn't just about allowing Google to use the code, but also the contributor's guarantee that they have the rights to commit the changes they are making. On Saturday, March 29, 2014 9:28:22 PM UTC-5, Thomas Broyer wrote: On Sunday, March 30, 2014 3:41:33 AM UTC+2, Benjamin Possolo wrote: I am interested in helping modernize the gwtproject.orgwebsite/documentation and part of that effort would include moving the code to GitHub. I think GitHub provides a certain amount of credibility that lacks with the current Gerrit system. Do you imply that the same system that is used for Android and ChromiumOS lacks credibility? The same that's also used by Eclipse, OpenStack, Typo3, Qt, Wikimedia, etc. https://code.google.com/p/gerrit/wiki/ShowCases Moving to GitHub would encourage more people to contribute and get involved because they are familiar with the github UI and the process for submitting pull requests, performing code reviews, etc. I agree GitHub is more familiar to many than Gerrit, and that would probably ease contributions. But, as far as I'm concerned, I wouldn't move to GitHub (at least for GWT proper). The main reasons we chose Gerrit were: * side-by-side diffs * enforcing a clean history (this is particularly important as Google syncs their internal Perforce repo with the public Git repo, the history needs to be linear for them) The website doesn't have those clean history constraints, but it'd be a bit strange to use another system to review changes for the website than changes to GWT proper (note that I'm not strongly against it) I believe you can find some discussions on the subject in the archives of https://groups.google.com/d/forum/gwt-steering At GitHub, to maintain a clean history means that you either ask every contributor to rebase and squash their branches before you can merge them, and/or you rebase and squash them yourself when merging, but it at least means being very careful when clicking the merge button (so careful that you'd probably want to disable it –that's not possible– and force every commiter to merge manually with --ff-only or --squash). We're starting seeing integrations between Gerrit and GitHub ( http://gerrithub.io/), so who knows, maybe one day that plugin will be available on gwt-reviews so contributors will be able to submit changes as GitHub Pull Requests rather than pushing them to Gerrit. In the mean time, I believe what we need is better documentation. Our making GWT better web page is really light. Patches welcome. Not to mention, it is simply much more social and transparent. !? I could understand the more social argument (although I don't think it's a compelling one), but more transparent? It sounds like Gerrit has a feature that only allows patches from people that have signed contributor legal agreements. I guess I don't really understand why this is necessary now that GWT has become fully open sourced and is no longer owned by Google. Required reading: http://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/and http://www.clahub.com/pages/why_cla Ideally, the GWT Project would be a legal organization so you'd sign a CLA with the GWT Project. But it's not, so you still sign an agreement with Google. However, if this is actually necessary, couldn't we simply use a git commit hook to enforce it? Yes, there are things like CLAHub; but you need to train all committers to not look at patches until the CLA has been signed, it's not enforced. Similarly, GitHub hooks with the PR status API can inform you of the build status of a pull request, but nothing prevents you from merging it. On the other hand, merging a change that fails to build in Gerrit needs special permissions (even though we don't do a full build, so in practice a change can still break the build without failing the pre-check) AngularJS is on GitHub..doesn't make sense to me why Google Web Toolkit can't be. Well, it is (https://github.com/gwtproject) but only as a mirror (to make forks easier), and not for all projects (it's probably just a matter of asking GitHub to mirror the missing projects). The issue tracker is still at code.google.com
Re: [ERROR] Line XX: Unexpected exception while processing element 'property-provider'... shell failed in doStartup method
Jens is dead on - several API changes from 2.4/2.5 to 2.6 make it difficult for a library to stradle that divide. We'll be shipping a GXT 3.1 beta Real Soon Now to enable users to switch to GWT 2.6. Breaking changes include: - Changing permutations (ie6 and opera are gone, ie10 was added, note that newer versions of opera are webkit based and do not need their own permutation) - Element added new final methods hasClassName and toggleClassName that can't compiled with XElement methods of the same name - String utils methods removed, switched to newer version of Guava (which now uses those methods) On Thursday, February 13, 2014 1:35:32 AM UTC-8, Jens wrote: Your Sencha GXT library is most likely not compatible to GWT 2.6. I guess you need to update GXT if possible or go back to GWT 2.4 or 2.5.1 (whatever works). -- 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/groups/opt_out.
Re: SuperDevMode not so super
There is a prototype project enabling Eclipse to debug the JS running in the browser with sourcemaps - check it out at http://github.com/sdbg/sdbg. On Thursday, November 15, 2012 8:46:26 AM UTC-8, Clint Gilbert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I could hook Eclipse up to Firefox or Chrome and step through code, that would make SDM much more workable. Is that currently possible? If so, is it possible to inspect the internal state of an object defined in Java, compiled to JS, and running in a browser VM? Breakpoints and stepping line by line are great, but losing object inspection would be a big step back. On 11/14/2012 09:58 PM, Chris Lercher wrote: On Thursday, November 15, 2012 2:53:37 AM UTC+1, Thomas Broyer wrote: SourceMaps could then be used by your IDE so you could put breakpoints in your editor window. I can see the potential - it could be big. I do have a few doubts though: 1. Would this also allow me to inspect the internal state of objects from within my IDE? (Is this even possible?) 2. What about super-sourced classes, which are - at least in Eclipse - usually excluded from the build path to avoid error messages (that's probably the smaller problem, as I imagine, that this could be taken care of by the IDE plugins) Embedded browsers, even if using the exact same engine, don't behave like their full blown counterparts (IE, when embedded, has different rules for switching between IE5.5Quirks/IE7/IE8/etc. modes for instance) I think, living with these differences in Dev Mode would be ok. The situation was different back in Hosted Mode's time, because Super Dev Mode was missing. I believe, that Dev Mode currently has some important use cases, which Super Dev Mode can't cover (yet?) For these use cases, the browser differences are often not that important. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/65KGTSLnUJ0J. To post to this group, send email to google-we...@googlegroups.com javascript:. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClHDEACgkQ5IyIbnMUeTsejwCcCepJDymqjpECsv7PXhXnbciF L9gAn34/OEEJArXpXU6zq+10OlSmvs2L =QD9T -END PGP SIGNATURE- -- 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.
[gwt-contrib] Re: bug in permutations.js?
In CrossSiteIframeTemplate.js this is handled by assigning
__MODULE_FUNC__.__softPermutationId to 0 to begin with, and then only
change that value if : was present in the permutation string. I'm not
seeing any other js files that init __softPermutationId to 0, and only
permutations.js assigns it to another value (but does so conditionally, so
it never *assigns* undefined to __softPermutationId, it just leaves it not
defined).
var idx = strongName.indexOf(':');
if (idx != -1) {
softPermutationId = parseInt(strongName.substring(idx + 1), 10);
strongName = strongName.substring(0, idx);
}
In researching
https://code.google.com/p/google-web-toolkit/issues/detail?id=8539
recently, this seemed to make sense (except in the context of the bug,
where the permutationId in CollapsedPropertyHolder where it gets
overwritten when it loads in a split point...). Looking at permutations.js,
it defines a method getCompiledCodeFilename(), but from a grep of the
codebase, this is only ever called from CrossSiteIframeTemplate.js, which
as mentioned above, sets a default value of zero.
The key direct_install maps to
com.google.gwt.core.linker.DirectInstallLinker, which extends
CrossSiteIframeLinker, and overrides getJsInstallScript to use
com/.../installScriptDirect.js instead of
com/.../installScriptEarlyDownload.js and change another boolean, but
neither of those appear to block getSelectionScriptTemplate from being used
to determine the actual selection script. Which should then mean that
softPermutationId gets init'd to zero.
That's just at a quick glance - aside from that I only have an absence of
evidence of the bug but no evidence of absence. We use a lot of soft
permutations, and 8539 is the only time we've seen an issue (where the
first time the value gets used is in a split point) - any chance that is
what is biting you instead?
On Thursday, February 13, 2014 11:41:50 AM UTC-8, Stephen Haberman wrote:
Hey,
We upgraded to GWT 2.6 last week, and our seeing weirdness with
StyleInjector. Firefox ends up using the StyleInjectImplIE and errors
out because $doc.createStyleSheet is IE only.
FF gets the wrong deferred binding because its permutationId is
undefined, when it should be 0. (We use collapse-all-properties and
direct_install linker.)
Looking at permutations.js, it does var softPermutationId, then later
when parsing the strongName, our FF strongName doesn't have : in it
(see below), so it ends effectively up doing:
module.__softPermutationId = undefined;
In our module.nocache.js file, here's the gecko1_8 entry:
unflattenKeylistIntoAnswers(['gecko1_8'],
'9181777BF8BB65802D36B21DCBB83FE1');
No :0 at the end.
So, surely __softPermutationId being undefined is a bug?
Should I try fixing this by changing getCompiledCodeFilename's
softPermutationId to default to 0? Or is the problem with the strong
name itself, in that it should always have a :digit suffix?
Hm. PermutationsUtil:131 insinuates :0 is left off on purpose.
Looking at git log/git blame, doesn't seem like any of this has changed
recently? We had been running some post-2.5 GWT trunk.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: gwt 2.6 SuperDevMode and injected css problem
With Super Dev Mode off, the browser simply loads the compiled code from the regular web server, so this suggests that either Super Dev Mode is being used as your regular server (and so only one copy of the app is available at a time, for the last browser it compiled for), or your normal compiled app is being compiled with those browsers turned off. The fact that SDM is able to generate code for those browsers suggests that the code itself is fine, and that either your project simply needs to be recompiled, or properties are set up in your .gwt.xml to exclude those browsers. Without seeing code or the running app, it is hard to be more specific. On Sat, Feb 8, 2014 at 11:50 PM, Vassilis Virvilis vasv...@gmail.comwrote: Hi Colin, The problem is when DevMod is off. As I said when when DevMod is on (with compile) everything works in all browsers. However when I am not developing I would expect that site would be working with the version of software currently deployed for all browsers and not only chrome. Right now I am getting blank pages in firefox and IE. Vassilis On 02/08/14 03:07, Colin Alworth wrote: Can you confirm that you are hitting the Compile button in each browser and that the SDM console is indicating that it is recompiling for each other user agent? It sounds as though you might be compiling when you start up one browser, then just turning dev mode on without recompiling in other browsers. On Friday, February 7, 2014 4:25:18 PM UTC-6, Vassilis Virvilis wrote: Helo everybody, I have enabled super dev mode and it works ok in chrome but fails in firefox and internet explorer. More specifically I added set-configuration-property name=devModeRedirectEnabled value=true / add-linker name=xsiframe / set-property name=compiler.useSourceMaps value=true / in my gwt.xml My application requires some css to be injected with Resources.INSTANCE.css().ensureInjected(); which I do as the first thing in onModuleLoad() When dev mode is on (the bookmartlet) everything is working in all browsers When dev mode if off only chrome is working. In firefox and IE css resources are not injected. Any ideas? Vassilis -- 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.
[gwt-contrib] ModuleDefLoader changes and CompilerContext
Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but I've also seen this trying to understand the general compiler changes that are happening in trunk gwt - is the CompilerContext really an essential part of ModuleDefLoader in general? From what I can see it is tracked as a local variable, but only used in the enforceStrictResources() check, which could just as easily be a boolean. For any synthetic module (which can't have any resources at all), this is a moot point so the context could be skipped entirely, and more generally it *seems* to just be a flag. CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and passes it to the JdtCompiler, which doesn't actually use it at all - that seems to be the extent of its use when you do a ModuleDef.getCompilationState (which now requires that context as an argument, even though the ModuleDef already should have that state from the previously mentioned ModuleDefLoader?). Precompile takes it to get the module and the options (instead of taking the module and the options), and the J2JSCompiler takes it just to read options. At least as of 2.6 branch, haven't done the same tracing through master just yet. So my question is two-fold: Is this the new way of avoiding too many sets of config types to track, and if so, why restore the old APIs so that the designer can use them in 2.6.1 instead of updating the designer to generate a simple context for its own needs? Assuming this is the future way of dealing with options/etc, won't the designer just break again as this becomes more and more necessary to hook into the compiler from outside? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext
Thanks for the reply - I'll keep watching ;). W.R.T. designer, since existing installs are already broken and GWT 3+ is going to again remove these deprecated methods, wouldn't it make more sense to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in mind that I don't know what other upcoming changes are coming, but I'm assuming that code like ModuleDefLoader will eventually have some advantages from the context objects, and designer can't just keep using this now-deprecated method forever.) On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote: On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth nilo...@gmail.comjavascript: wrote: Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but I've also seen this trying to understand the general compiler changes that are happening in trunk gwt - is the CompilerContext really an essential part of ModuleDefLoader in general? From what I can see it is tracked as a local variable, but only used in the enforceStrictResources() check, which could just as easily be a boolean. For any synthetic module (which can't have any resources at all), this is a moot point so the context could be skipped entirely, and more generally it *seems* to just be a flag. not all changers are in. there are more uses coming. CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and passes it to the JdtCompiler, which doesn't actually use it at all - that seems to be the extent of its use when you do a ModuleDef.getCompilationState (which now requires that context as an argument, even though the ModuleDef already should have that state from the previously mentioned ModuleDefLoader?). Precompile takes it to get the module and the options (instead of taking the module and the options), and the J2JSCompiler takes it just to read options. At least as of 2.6 branch, haven't done the same tracing through master just yet. So my question is two-fold: Is this the new way of avoiding too many sets of config types to track, and if so, why restore the old APIs so that the designer can use them in 2.6.1 instead of updating the designer to generate a simple context for its own needs? updating the designer code would leave existing designer installs broken. Assuming this is the future way of dealing with options/etc, won't the designer just break again as this becomes more and more necessary to hook into the compiler from outside? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gwt 2.6 SuperDevMode and injected css problem
Can you confirm that you are hitting the Compile button in each browser and that the SDM console is indicating that it is recompiling for each other user agent? It sounds as though you might be compiling when you start up one browser, then just turning dev mode on without recompiling in other browsers. On Friday, February 7, 2014 4:25:18 PM UTC-6, Vassilis Virvilis wrote: Helo everybody, I have enabled super dev mode and it works ok in chrome but fails in firefox and internet explorer. More specifically I added set-configuration-property name=devModeRedirectEnabled value=true / add-linker name=xsiframe / set-property name=compiler.useSourceMaps value=true / in my gwt.xml My application requires some css to be injected with Resources.INSTANCE.css().ensureInjected(); which I do as the first thing in onModuleLoad() When dev mode is on (the bookmartlet) everything is working in all browsers When dev mode if off only chrome is working. In firefox and IE css resources are not injected. Any ideas? Vassilis -- 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: asm.js support?
There have been a few quick discussions about this in ##gwt on irc, and while I think we probably need to both move this to -contrib before much longer but also get some of the compiler experts involved, I suspect this is going to end up being a specific tool to optimize sufficiently c-like methods, not the entire application. The asm.js 'language' restricts down to just a few things - a TypedArray for a heap, standard lib (math, etc), and a variety of primitives. Within each module you can declare individual functions (as well as arrays of functions to do vtable sorts of things), and return a set of named functions to allow outside code to call into this asm-ified code. This appears to greatly limit what code can do. Since you are confined to a heap, there is no free GC, it has to be implemented (or garbage collect the whole heap with the rest of the module). Since the set of functions in the module is 'exported', and the module may be given a set of 'foreign' functions, it seems likely that individual GWT methods could be compiled to asm-compatible code if they meet certain criteria. The more complex the data going in and out is (i.e. serializing strings or complete objects to the 'heap', then deserializing to call foreign functions or to return again), the more expensive that each call will end up being, so either methods must opt in to this (via an annotation perhaps?), or the compiler has to have a pretty specific heuristic to decide if a method is eligible or not (for example, 'does this method take only primitive/primitive[] arguments, use only primitive/primitive[] fields, return a primitive/primitive[] value, and call only other methods which meet this same criteria?'). Then, methods should be grouped so that they share a heap and are only compiled once, so that they can start to deal with field in a consistent way without encoding/decoding (i.e. asm-ify all of an object's methods, store its fields in the heap, and GC the whole heap when the object itself goes away, and expose methods that can read out fields (getters/setters) directly from that heap). In short, the developer will likely need to be very aware of what GWT is going to try to do it their code and monitor something like the compiler report to see why a particular slow method isn't getting asm-ified. Ümit's point is probably right that for general purpose code, compiling code that the browser can handle efficiently while still viewing it as JS is a far easier win. But since the asm-ification has to be done to the JS code itself, I doubt that simply a library will make it possible to produce asm-compatible code, but instead that the compiler will need to be aware and actively participating, unless all such code is to be written in JSNI. On Tuesday, February 4, 2014 7:42:12 AM UTC-6, Ümit Seren wrote: What is your use case ? AFAIK asm.js is only intended as a highly efficient backend/LLVM for C++/C code (emmscripten). It's quite low level and usually as a programmer you don't directly code against asm.js (it is quite painful to work with: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html). In addition to this traditional web-development (DOM/CSS, javascript code) won't won't really benefit from asm.js. It would be only beneficial for games and computational (scientific) workloads (maybe create a library similar to Elemental for that use case). If you are concerned about performance than it would be better to push for the GWT compiler to emit code that is optimized for modern javascript engines (V8, etc). On Monday, February 3, 2014 6:29:30 PM UTC+1, Bora Ertung wrote: Are there any plans for asm.js support for GWT compiled code? Chrome has started support asm.js optimizations and I think it is about time to add this into GWT. any ideas? -B -- 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.
[gwt-contrib] Re: GWT + Maven - Using gwt-dev package as dependency
If you know enough to start writing generators, it almost certainly is not a concern - you are probably also careful with which GWT version you are using as well as which gwt-m-p version. A problem can occur if more than one version of gwt-dev is present on the classpath, such as a mistakenly declared copy in your dependencies and the copy that gwt-m-p automatically pulls in. Provided both versions are the same or care is taken to ensure that gwt-m-p uses the same dependency, there is no issue. See http://mojo.codehaus.org/gwt-maven-plugin/user-guide/using-different-gwt-sdk-version.html for how to configure your project to allow for different GWT SDK version from the maven plugin. I typically use two different properties, one for gwt.version, and a second for gwt.plugin.version with this strategy to allow them fall out of sync in a safe way. On Friday, February 7, 2014 11:09:23 AM UTC-6, Gilberto Torrezan Filho wrote: Hi, I'm using GWT 2.6.0 with Maven, using the gwt-maven-plugin, and in my project I have some auto generated classes (using the generated-with directive on Module.gwt.xml). The generator is a subclass of com.google.gwt.core.ext.Generator. The problem is: every time I build my project, Maven emits a warning: [WARNING] Don't declare gwt-dev as a project dependency. This may introduce complex dependency conflicts ... but I have to declare gwt-dev as dependency, since I need it to compile my code generator. I never faced any conflict - maybe because I'm declaring gwt-dev with the provided scope, avoiding it to be part of the generated war. So, in this scenario, is that warning still accurate? Is there any other way to avoid it (while still having the code generators)? Thanks. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: XSS in GWT
For JSON, you'd have go pretty far out of your way to get attacked, like loading something untrusted via JSONP, or manually parsing your own json with eval (rather than any of the safe built-in tools), or, ya know, forgetting to run SSL and having someone intercept your server communication. This isn't GWT specific, you just have to ignore basic web security stuff for these. GWT doesn't run on the server, so XSRF issues don't really apply to GWT itself. To be attacked in this way, the server needs to accept requests from remote (i.e. attacking) sites without doing something to confirm that they came from the real app. The default RPC and RequestFactory servlets don't do any session or auth management, so don't have a specific vulnerability, but a POST sent to them from an attacking site that is treated as a request from the app itself entirely based on the contents of a cookie (i.e. jsessionid) could be an attack vector. As I said though, RPC/RF don't build in any security but leave it to the app to decide what a user is, what a session is - the code that is reading the HTTP request and deciding that a request is valid is responsible for that. Both RPC and RF have ways to add some content to the body that keyed off of something only a real request from the user should know. On Tuesday, January 28, 2014 2:22:03 PM UTC-6, Kurt Dmello wrote: Thanks folks, This is great stuff. Keep it coming ! I am looking for all potential points of interest in a code review. Including XSRF and JSON related vulnerabilities. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Quarterly Hangouts On Air
The concern I've heard expressed during in-person discussions about how to do this is that a written document of answers 'feels' more real and concrete than a group of people answer questions live, since they clearly have no chance to vet their answers from their own organization or with each other. As long as the questions stay in the realm of what GWT currently is, that wouldn't be an issue, but when we start jumping into the When will IE X support be dropped or When will Java Y support be added or Why isn't my library being added to GWT territory, the panelists may feel as though it is safer to just leave the questions un-answered. That said, this would be keeping in the reddit ama form... With a live speaker and panel, if no one answers a question, the dead airs gets to people, and someone steps up to try an answer or at least rephrase the question, even though the answer might be qualified (this is just my opinion), or vague (we're still working through the specifics). BTW, there is a /r/gwt already, we could start there for some informal stuff (weekly/monthly AMAs), and then do a slightly more official call quarterly? On Tue, Jan 28, 2014 at 9:59 AM, James Nelson ja...@wetheinter.net wrote: A reddit-style AMA would be really cool; so long as we give enough warning and promo, (like posting the event in the G+ community a month ahead of time) I'm sure it would be a hit. The questions in the moderator would probably all get asked; though seeing some of them come up in the gwt-team meetings would be cool too. An actual hangout over a single time slot generally leaves a lot of people unable to come, so, maybe we'll see if we can keep attracting a lot of people to the community meetings, and maybe we'll get a greater audience to steering committee meetings. The only reason I was not viewing the public committee meetings was visibility; my gwt-contrib emails were getting filtered with hundreds of other group emails, so I didn't really keep up (have since create a filter specifically for Gwt). I am going to email Bhaskar to see if I can get plugged in on the meeting tomorrow, and I bet if we post it on G+, we'll see greater developer interest. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: XSS in GWT
Another set of dangerous code to look for would be any SafeHtmlUtils or SafeHtmlBuilder (and their uri/style conterparts) call that should take 'constant' or 'trusted' but instead takes untrusted user data. Custom implementions of SafeHtml should also be treated as suspect. These all fall under the category of Deliberately abusing the safehtml api will make it no longer safe. On Tuesday, January 28, 2014 11:17:49 AM UTC-6, Thomas Broyer wrote: On Tuesday, January 28, 2014 5:04:08 PM UTC+1, Kurt Dmello wrote: Hey folks, I am a relative noob to GWT and have been looking at it from a security code review perspective. I want to create a set of guidelines for people who have to review GWT code from a security perspective looking for vulnerabilities. I have read and understood : http://www.gwtproject.org/articles/security_for_gwt_applications.html I have also implemented the StockWatcher application by following the tutorial. In trying to introduce vulnerabilities that I could exploit as a demonstration for what to look for I have failed. My understanding after reading the article on GWT security was that if tainted data is set using setHTML() or setInnerHTML() on a client widget it will be suceptable to XSS. I found the HTML() widget to contain a setHTML() routine that took a String and not SafeHTML and set its value to contain a variety of standard XSS exploits such as scriptalert(1);/script. It does not produce the expected results. It seems to me that there is a black list or further escaping that happens underneath the covers. Is it that I am simply out popping out to the right context or is GWT truly immune to XSS. What you're seeing here is browser sanitization from innerHTML (not sanitization actually, just that the script are not run). Try with img onerror=alert(1) src=// or similar (onclick, etc.) What should someone performing code review on a GWT app. be looking for ? Everywhere SafeHtml / SafeStyles / SafeUri could be used but is not (HasHTML#setHTML is one such things) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] gwtproject.org link tree broken
Something funny has happened to the dont-reload-the-page code on gwtproject.org, but I'm not seeing any obvious commit that should have done this. Steps to repro: 1) visit http://gwtproject.org/, or any *top level* document 2) observe that any link you hover looks to be correct, and visiting any link will work correctly (including opening it from a new tab 3) Click on any *nested* link (such as something inside of articles or documentation latest ). 4) Now, hover over any link, and notice that the subdirectory you are currently in will be prepended to the link url 5) Open that link in a new tab, observe that you get a 404. Example: Go to http://gwtproject.org/. Expand Documentation, Latest, and click on Overview. Right-click Accessibility, and select 'open in a new tab' Observe 404 error page, and obviously broken url: http://www.gwtproject.org/ *doc/latest/doc/latest/*DevGuideA11y.html The source at https://gwt.googlesource.com/gwt-site-webapp/+/master/ hasn't been updated since early December, and I can't imagine this has been broken that long, and none of the recent commits to gwt-site itself seem capable of this, so I'm at a bit of a loss as to how this could have happened. Were there perhaps any changes made that didn't go through googlesource.com, or has this really been broken for months? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Questions remain for the GWT.create Steering Committee members
Another thought: Christian Sedilek, Dan Kurka, and myself can also be found pretty frequently in ##gwt on irc.freenode.net for a more informal discussion - I'd love to see more steering committee members hang out there, even if just idling most of the time, and chatting once in a while. Keeping these discussions as 'conversations' rather than as written documents probably helps them to stay a little more informal - rather than feeling like we're describing our collective vision for what GWT will be in 6, 12, 18 months, we get to be a little more interactive to hear about what people need GWT to be, and we get to float some ideas out there. From my perspective, that was an important step at the SF conf, getting us all to hear about concerns around SDM - since that panel discussion, I've switched my local development to about 80% sdm to try to come up with more concrete ways to improve how we document it and encourage people to use it. In Frankfurt, we fielded fewer online questions and got more from the room, and seemed to center around how GWT will change going forward - which browsers can be dropped, how we might continue to make Dev Mode work or otherwise keep in-IDE debugging. On Thursday, January 2, 2014 9:56:39 AM UTC-6, Daniel Kurka wrote: Just an idea: We could think about doing a hangout maybe every quarter with a pre populated moderator. On Tue, Dec 17, 2013 at 4:09 PM, Michael Prentice spla...@gmail.comjavascript: wrote: That would be great. I know that they are busy with the EU conference this week, but there were a lot more questions to be addressed. I already gave some feedback that we might need to expand the panel QA's next year (either split them by some topics or extend the time). On Monday, December 16, 2013 3:58:07 PM UTC-5, Boris Brudnoy wrote: Hello, The closing session of the GWT.create 2013 US saw a panel of the GWT Steering Committee members answer attendee questions. It so happened that the issue of the changing debugging tools hijacked (most of) the conversation but there were plenty more good questions the attendees entered on the Moderator page for the panel: https://www.google.com/ moderator/#7/e=21396f. I am wondering if perhaps the Steering Committee members could find time to address the remaining questions in writing and, for example, post it on the G+ community page? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: 2.6.0-rc3
This system property isn't listed when either dev mode or the compiler runs because it is a system property, not a program arg. It should be provided with the other VM args when you start Java. These aren't listed as part of the normal properties, but are documented here: http://code.google.com/p/google-web-toolkit/wiki/JavaSystemPropertiesAndGwt We probably should migrate that table (and expand it?), but for the most part these are used to tweak internals that shouldn't normally be needed. In the case of the issue I'm pointing out with java6, it appears that this issue is only due to a build problem when the RC was originally compiled. The only other flag I use in the list with any regularity is gwt.jjs.traceMethods, which lets you see what the compiler is doing with each method as it works. On Sun, Dec 8, 2013 at 5:28 PM, Juan Pablo Gardella gardellajuanpa...@gmail.com wrote: Thanks Thomas! 2013/12/8 Thomas Broyer t.bro...@gmail.com On Sunday, December 8, 2013 2:12:31 PM UTC+1, Thomas Broyer wrote: On Saturday, December 7, 2013 7:42:42 PM UTC+1, juan_pablo_gardella wrote: HostedMode appears in http://www.gwtproject.org/doc/latest/ DevGuideCompilingAndDebugging.html at the section Development Mode Options. Will fix. See https://gwt-review.googlesource.com/5651 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: 2.6.0-rc3
Workaround: add -Dgwt.usearchives=false to your jvm args when invoking the tests or dev mode. From maven this uses the extraJvmArgs param: http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#extraJvmArgs. On Friday, December 6, 2013 1:03:57 AM UTC-6, Roberto Lublinerman wrote: It seems that we need to build the release with -sourceLevel 6 for it to work with Java 6. On Thu, Dec 5, 2013 at 10:43 PM, Colin Alworth nilo...@gmail.comjavascript: wrote: Sorry for being unclear - I'm building/testing an application that makes use of GWT while still on Java6, not building/testing GWT itself. I'm trying to sanity test rc3 as a candidate for a final release of 2.6.0, and as far as my testing goes, this is the only point it is failing. To clarify the point about the references to Matthew's machine, unzip the gwt 2.6.0-rc3 download on code.google.com, unpack the gwt-user.jar file, and try this: $ strings com/google/gwt/core/Core.gwtar | grep file | head fileNameq bfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/AsyncProvider.javat fileNameq ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Callback.javat fileNameq jfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/CodeDownloadException.javat fileNameq ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Duration.javat fileNameq fileNameq On Friday, December 6, 2013 12:10:10 AM UTC-6, Roberto Lublinerman wrote: Hi Colin, Did you do ant clean? I find it strange that the resource points to Matthew's hard drive, as if Impl was precompiled by him (and in that case probably is consistent that the version is 51.0). I build from scratch in my laptop (only has java 1.6) and builds and tests run fine. Is there a specific application that you are trying to build? On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth nilo...@gmail.com wrote: I'm still running into trouble with the major version of the compiled classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As before, I was able to confirm that the actual .class files are compiled correctly, but yet I get fatal errors in attempting to run dev mode. Testing so far is on a mac with 1.6.0_65: $ java -version java version *1.6.0_65* Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) $ javap -v com.google.gwt.core.client.impl.Impl | head Compiled from Impl.java public final class com.google.gwt.core.client.impl.Impl extends java.lang.Object SourceFile: Impl.java InnerClass: public abstract #77= #76 of #170; //UncaughtExceptionHandler=class com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class com/google/gwt/core/client/GWT minor version: 0 major version: *50* Constant pool: const #1 = Method#61.#163;// java/lang/Object.init:()V const #2 = Field#55.#164;// com/google/gwt/core/client/ impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport; When in dev mode, I've seen this error: 22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module entry point class null (see associated exception for details) java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass( CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass( CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName( ModuleSpace.java:670) at com.google.gwt.dev.shell.ModuleSpace.onLoad( ModuleSpace.java:359) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule( OophmSessionHandler.java:200) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection( BrowserChannelServer.java:526) at com.google.gwt.dev.shell.BrowserChannelServer.run( BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:695) When running unit tests in dev mode with HtmlUnit, I've seen this: [ERROR] Unable to load module entry point class null (see associated exception for details) [junit] java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 [junit] Dec 5, 2013 10:51:41 PM com.gargoylesoftware.htmlunit.WebConsole info [junit
[gwt-contrib] Re: 2.6.0-rc3
I'm still running into trouble with the major version of the compiled classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As before, I was able to confirm that the actual .class files are compiled correctly, but yet I get fatal errors in attempting to run dev mode. Testing so far is on a mac with 1.6.0_65: $ java -version java version *1.6.0_65* Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) $ javap -v com.google.gwt.core.client.impl.Impl | head Compiled from Impl.java public final class com.google.gwt.core.client.impl.Impl extends java.lang.Object SourceFile: Impl.java InnerClass: public abstract #77= #76 of #170; //UncaughtExceptionHandler=class com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class com/google/gwt/core/client/GWT minor version: 0 major version: *50* Constant pool: const #1 = Method#61.#163;// java/lang/Object.init:()V const #2 = Field#55.#164;// com/google/gwt/core/client/impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport; When in dev mode, I've seen this error: 22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module entry point class null (see associated exception for details) java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:695) When running unit tests in dev mode with HtmlUnit, I've seen this: [ERROR] Unable to load module entry point class null (see associated exception for details) [junit] java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 [junit] Dec 5, 2013 10:51:41 PM com.gargoylesoftware.htmlunit.WebConsole info [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] INFO: /launch error: Failed to load module com.example.SampleProject.JUnit. [junit] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) [junit] Please see the log for details. [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:621) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:471) [junit] at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) [junit] at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [junit] at java.lang.Class.forName0(Native Method) [junit] at java.lang.Class.forName(Class.java:249) [junit] at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670) [junit] at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359) [junit] at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200) [junit] at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526) [junit] at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) [junit] at java.lang.Thread.run(Thread.java:695) It has been driving me nuts trying to track down what mistake I could possibly be making - I've tried explicitly adding -sourceLevel 1.6 to the arguments (which parses correctly, I set breakpoints to avoid the possible null issue reported for java 8), but this hasn't seemed to have any effect. I'm willing to admit user error, but the really odd thing about this is that if I debug com.google.gwt.dev.shell.rewrite.WriteJsoImpl.ForJsoDollar's ctor or com.google.gwt.dev.asm.ClassWriter.toByteArray() I can pick out that some objects have version 49, some have 50, and at least one has 51 (which under java 6 is fatal). Here's the stack at this point, paused on a case where version is
Re: [gwt-contrib] Re: 2.6.0-rc3
Sorry for being unclear - I'm building/testing an application that makes use of GWT while still on Java6, not building/testing GWT itself. I'm trying to sanity test rc3 as a candidate for a final release of 2.6.0, and as far as my testing goes, this is the only point it is failing. To clarify the point about the references to Matthew's machine, unzip the gwt 2.6.0-rc3 download on code.google.com, unpack the gwt-user.jar file, and try this: $ strings com/google/gwt/core/Core.gwtar | grep file | head fileNameq bfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/AsyncProvider.javat fileNameq ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Callback.javat fileNameq jfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/CodeDownloadException.javat fileNameq ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Duration.javat fileNameq fileNameq On Friday, December 6, 2013 12:10:10 AM UTC-6, Roberto Lublinerman wrote: Hi Colin, Did you do ant clean? I find it strange that the resource points to Matthew's hard drive, as if Impl was precompiled by him (and in that case probably is consistent that the version is 51.0). I build from scratch in my laptop (only has java 1.6) and builds and tests run fine. Is there a specific application that you are trying to build? On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth nilo...@gmail.comjavascript: wrote: I'm still running into trouble with the major version of the compiled classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As before, I was able to confirm that the actual .class files are compiled correctly, but yet I get fatal errors in attempting to run dev mode. Testing so far is on a mac with 1.6.0_65: $ java -version java version *1.6.0_65* Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) $ javap -v com.google.gwt.core.client.impl.Impl | head Compiled from Impl.java public final class com.google.gwt.core.client.impl.Impl extends java.lang.Object SourceFile: Impl.java InnerClass: public abstract #77= #76 of #170; //UncaughtExceptionHandler=class com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class com/google/gwt/core/client/GWT minor version: 0 major version: *50* Constant pool: const #1 = Method#61.#163;// java/lang/Object.init:()V const #2 = Field#55.#164;// com/google/gwt/core/client/impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport; When in dev mode, I've seen this error: 22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module entry point class null (see associated exception for details) java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) at java.lang.Thread.run(Thread.java:695) When running unit tests in dev mode with HtmlUnit, I've seen this: [ERROR] Unable to load module entry point class null (see associated exception for details) [junit] java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0 [junit] Dec 5, 2013 10:51:41 PM com.gargoylesoftware.htmlunit.WebConsole info [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] INFO: /launch error: Failed to load module com.example.SampleProject.JUnit. [junit] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) [junit] Please see the log for details. [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:621) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:471) [junit] at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121
Re: PieChart stays in detached DOM tree when removed from parent widget
Good to know - that makes it seem rather likely that this leak is entirely within the core visualization code, rather than anything specific to gwt. I would look at plain JS examples of how to use the library, and make sure that a step isn't being missed either by virtue of writing in GWT or by just forgetting to call some cleanup method. It may also be that if you write this same code in pure JS, there will be a leak and that you cannot do anything about it. On Wednesday, December 4, 2013 12:21:23 PM UTC-6, ak...@ualberta.net wrote: Hi Colin, https://lh4.googleusercontent.com/-sPqHnXrVFXk/Up9xLWDPTkI/ABI/eMFgyy-yBuM/s1600/Screen+Shot+2013-12-04+at+11.04.40+AM.png Thanks for replying so quickly. I've tried compiling with -Dgwt.style=PRETTY and even DETAILED, but the short variable names remain for DOM objects created by, or at least related to, gwt-viz. Using Chrome's dev tools, I can look inside these objects to verify the connection to gwt-viz. https://lh4.googleusercontent.com/-sPqHnXrVFXk/Up9xLWDPTkI/ABI/eMFgyy-yBuM/s1600/Screen+Shot+2013-12-04+at+11.04.40+AM.png I've trimmed the code down to a minimal test case (attached). Should you decide to try compiling and running it, don't forget to to inherits name='com.google.gwt.visualization.Visualization'/ in the *.gwt.xml file. -- 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: PieChart stays in detached DOM tree when removed from parent widget
Can you try compiling in PRETTY? This will make the retaining tree graph in chrome's inspector easier to tell where things are coming from and what is tracking them. But at a glance, something registered something with google.visualization, and didn't unregister it. Knowing what gD, iv, and fv are in that tree might give you a better hint about what might be stuck - another callback, a different instance, etc. On Tuesday, December 3, 2013 2:44:50 PM UTC-6, ak...@ualberta.net wrote: I posted this to Stackoverflowhttp://stackoverflow.com/q/20129862/770519and to the gwt-vizualization team as a possible bug http://code.google.com/p/gwt-google-apis/issues/detail?id=529, but I have not received any replies from either post. Perhaps someone here has some insight into what is going on, or knows someone on the gwt-google-api team, or is on the team. I have an MVP GWT 2.5.1 app using version 1.1.1 of gwt-visualization. My view has two Buttons and a VerticalPanel (accessed by the presenter as display.getPanel()). One button adds a PieChart to the VerticalPanel, the the other removes it. The presenter holds the PieChart reference as a Widget so that it knows when it has been added/removed. It is initialized to null. I checked chrome's dev tools to ensure that the add/remove code wasn't creating a DOM leak. But after the PieChart was removed, its elements were left behind in a detached DOM tree, all color coded red. When I tried the same add/remove code with a Label instead of a PieChart, no detached DOM tree remained after removal. I have a project on github that will reproduce this: git clone https://github.com/akydd/GWT-experiments.git Clone, build it, and deploy it so it can be run in Production mode. It should have the following URL if deployed to the root folder of your local webserver: http://127.0.0.1/WidgetAddDelete.html. Open it up in Chrome. To see the issue, click the button on the first screen. You should now see multiple buttons on screen. Click Add chart, wait for the chart to draw, then click Remove chart. Using Chrome's dev tools, take a heap snapshot. You should see about 36 elements in the detached DOM tree that are left over from the removed PieChart: https://lh5.googleusercontent.com/-Y1HQk_ZEjW4/Up5CgM_qnlI/AA4/EsZB2I9nExU/s1600/Screen+Shot+2013-12-03+at+1.38.30+PM.png It looks to me that there is a DOM leak with the PieChart widget. Can someone confirm? Or perhaps there is another way that I should be removing the PieChart widget? I'm using the HasWidgets interface methods add(Wudget w) and remove(Widget w) to add and remove, respectively. -- 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.
[gwt-contrib] Re: 2.6.0-rc2
What's the current thinking on removing ImageResource.isStandalone from 2.6.0 final, as in the https://gwt-review.googlesource.com/#/c/5504/ review? It isn't in GWT 2.5.x, and isn't in master, but is present in both 2.6.0-rc1 and 2. If it was an oversight to add this the first time around, shouldn't it be dropped from 2.6 before it goes final? Aside from that, seems to be passing all our smoke tests so far, will have more comprehensive results tomorrow. -Colin On Monday, December 2, 2013 4:49:29 PM UTC-6, Matthew Dempsky wrote: I cut a new 2.6.0 release candidate this morning: 1. There's a 2.6.0-rc2 tag in git. 2. The gwt-2.6.0-rc2.zip is available on Google Code: https://code.google.com/p/google-web-toolkit/downloads/list 3. I've pushed a 2.6.0-rc2 release to Maven Central (as usual, I think it takes an hour or so to be available). We originally planned to make the final release today, but I had forgotten to take Thanksgiving into account, so I think we'll push the release back until next week. I'd appreciate if people could help test and wring out any remaining bugs. There's still the outstanding version warning from GPE, but a fix for that has already been submitted, and a new GPE release will hopefully be available in the next few days. Changes since 2.6.0-rc1: https://gwt.googlesource.com/gwt/+log/2.6.0-rc1..2.6.0-rc2 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Officially deprecating Opera permutation
Just to confirm, the plan is to set this in master as well as releases/2.6, and this will go out in 2.6.0-rc2? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Firefox in OS X freezes in DevMode.
Jorel, I am myself not yet using Mavericks (others on my team are, that's where I'm drawing from for my other reply), so am running 10.8.5 and firefox 25, but can't reproduce this issue. Do you have any error messages or logs to share? To everyone who has managed to workaround the issue with root, instead can you try a new profile in your normal firefox instance under your normal account? On Saturday, November 16, 2013 10:39:58 PM UTC-6, Jorel wrote: I'm also seeing this on a mac running 10.8.5 (not yet on mavericks). Firefox 25 upgrade did something to my config i guess. Running Firefox as root also solved this. I would be interested to find out why this workaround is necessary ... glad to have a workaround for now though. On Thursday, November 14, 2013 1:02:21 PM UTC-5, Jonathan Strootman wrote: This is happening to some of our guys too. We used the workaround that Carlos mentioned, launching FF as root. On Saturday, November 9, 2013 9:52:55 PM UTC-7, Carlos Aguayo wrote: I really appreciate your help Colin. At this point I believe it's some misconfiguration in my computer. I tried to do a jconsole on the devmode process and it said it couldn't connect to it. I then did a jstack and said the same but this time the utility suggested to use a -F to force it, when I did that, I was able to see the threads. I then tried to launch firefox and sudo mode, and voila, that worked! So I open Firefox in normal mode, it can't connect to the plugin, I then try it in root mode and works... The devmode process and eclipse are running with my account, so I can't tell what else I could have messed up but the important is that I can work and move on. I appreciate the help, On Saturday, November 9, 2013 3:10:58 PM UTC-5, Colin Alworth wrote: If you can repro this on at least one other machine and get the details of what the JVM is doing, that'd be helpful. I have a very basic familiarity with the dev mode code from researching the FF dev mode memory leak, and would be happy to take a closer look. From your description it sounds like the JVM is either also waiting for the browser (and we'll need to figure out how it got into that bad state with one having ignored a message from the other), or the JVM is blocked on something else entirely, the real source of the bug. My bet is on the latter, that something funny is going on there. Recent updates to Dev Mode were made for all platforms, nothing mac-specific, so that seems unlikely. Getting an old copy of firefox and an old (pre-ff25) copy of the plugin would probably be worth testing as well if you are able to repro this on more than one box. Note: the FF-devmode memory leak has to do with the old pages failing to shut down the plugin correctly, so make certain that you don't load more than once. If you do, your JVM will have two different threads trying to talk to the browser, and it may be difficult to tell which one is the current one, versus the 'memory leak' one. On Saturday, November 9, 2013 11:01:40 AM UTC-6, Carlos Aguayo wrote: Thanks Colin, yeah that's what I figured, initially I thought that it would be a problem in the plugin given that it was only blocking Firefox and only in OS X (given that Chrome worked and also Firefox but under Linux). I started debugging and got all the way there. I doubt that it's a breakpoint or having to wait for a long time as I did leave the browser for a few minutes, there's no breakpoints and CPU is not peaking, so I'd think there's something else waiting. I'll follow your suggestion and check now the other side, but it's good to know that you haven't had an issue with FF and Mavericks as then that would sadly imply that there's something wrong with my computer :(. On Friday, November 8, 2013 9:20:10 PM UTC-5, Colin Alworth wrote: Line 155: ssize_t n = recv(sock, readBuf, BUF_SIZE, 0); That seems to say 'block until bytes are written by the other end of the socket', or in other words, wait until the JVM is ready to go. Are you sure that the IDE isn't paused on a breakpoint, or that you have waited long enough for the page to load? When the browser is in this state, try pausing the JVM to see what the dev mode thread is doing - I'm betting it is hard at work on something... but if it too is waiting for something, that could be a problem. But the recv call is *supposed* to block, at least until dev mode has finished running its not-yet-JS code. We've had no issues with Mavericks and latest FF in our projects fwiw, aside from the usual 'dev mode takes longer to do anything' fun. On Thursday, November 7, 2013 10:59:18 PM UTC-6, Carlos Aguayo wrote: It's getting stuck in line 155 in: https://gwt.googlesource.com/gwt-plugins/+/master/common/Socket.cpp On Thursday, November 7, 2013 7:32:28 PM UTC-5, Carlos Aguayo wrote: I'm started to have issues when trying to use DevMode
Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?
There is a workaround - I'm on my phone now, but I posted it in the bug report. Essentially you can tell the plugin to not worry about invalid SDKs, and either mark then as merely errors, or just ignore it entirely. With that set, we've noticed no other I'll effects so far. On Nov 17, 2013 12:29 AM, gslender gslen...@gmail.com wrote: I assume there is no workaround whilst we are waiting for GPE to be updated for 2.6 ?? G On Wednesday, 30 October 2013 20:22:33 UTC+10, Jens wrote: We are start using GWT trunk builds for development but Eclipse / GPE always says GWT SDK ... on the projects build path is not valid (Version is not supported, must be 2.0.0 or later) if we add a trunk build to the list of GWT SDKs in Eclipse. In the list of GWT SDKs the version column is empty so it seems like Eclipse does not recognize any version. This happens for a typically GWT SDK 0.0.0 build and it also happens if I set the env.GWT_VERSION property to anything above 2.0.0. Is there anything I forgot to configure prior calling the ant script to make Eclipse happy? -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Integration tests for GWT
We're using this at Sencha with pretty good success, though it really is designed to be for testing applications, not libraries. I know of a few GXT customers who are using it with gxt-driver for widget support, but it is still pretty early - either everyone thinks it works out great, or there are problems that no one has bothered to tell me... I wrote gwt-driver to be as general as possible and do all the GWT-specific stuff of understanding widgets and talking to webdriver, and then I also wrote gxt-driver as a set of GwtWidget objects that are specific to GXT. I wouldn't go so far as to say that it is 'easy' to extend for custom made widgets, but if you have a grasp on how WebDriver works and are familiar with the basic setup of the custom widget it certainly shouldn't be hard. Both gwt- and gxt-driver are apache licensed, so use and copy freely (and of course pull requests are welcome!), as is a sample app/test that I put together for demonstration purposes at https://github.com/niloc132/gwt-driver-sample. There are a few open issues, mostly docs and logging, and I would absolutely welcome new ones, doubly so if they come with pull requests and tests! -- 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: Gwt client-side only needed files
None of the WEB-INF/ directory should be needed, provided you are not running a servlet container, but that is the only 'server-only' code that generally is created that will take up any meaningful size. Another option at your disposal is to get rid of the permutations and instead make just one permutation that contains details about every browser, instead of splitting it up to give each browser only what it needs. Easiest way to do that is to add collapse-all-properties / to your config file. More on that and other ways to skip some permutations at http://code.google.com/p/google-web-toolkit/wiki/SoftPermutations On Wednesday, November 13, 2013 3:11:32 AM UTC-6, gianmarco ascenzo wrote: Hi everyone, I'm using gwt for a web only client-side application, I have few KB available on device and then i can't export all war directory because much more big of disk size.I would like to compress it, if possible, in one file or removing unused part from war directory to lighten project. Does anyone know how could I do? Thanks for replies. -- 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: Integration tests for GWT
Another new toy to propose for saner Selenium testing: https://github.com/niloc132/gwt-driver On Monday, November 11, 2013 8:59:49 AM UTC-6, Ed wrote: If you search the forum well, you will find all you need.. Example: LINKEhttps://groups.google.com/forum/#!searchin/google-web-toolkit/awesome$20testing$20gwt/google-web-toolkit/hwMKmuZv4BI/RxUE16VoTa8J -- 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: Firefox in OS X freezes in DevMode.
If you can repro this on at least one other machine and get the details of what the JVM is doing, that'd be helpful. I have a very basic familiarity with the dev mode code from researching the FF dev mode memory leak, and would be happy to take a closer look. From your description it sounds like the JVM is either also waiting for the browser (and we'll need to figure out how it got into that bad state with one having ignored a message from the other), or the JVM is blocked on something else entirely, the real source of the bug. My bet is on the latter, that something funny is going on there. Recent updates to Dev Mode were made for all platforms, nothing mac-specific, so that seems unlikely. Getting an old copy of firefox and an old (pre-ff25) copy of the plugin would probably be worth testing as well if you are able to repro this on more than one box. Note: the FF-devmode memory leak has to do with the old pages failing to shut down the plugin correctly, so make certain that you don't load more than once. If you do, your JVM will have two different threads trying to talk to the browser, and it may be difficult to tell which one is the current one, versus the 'memory leak' one. On Saturday, November 9, 2013 11:01:40 AM UTC-6, Carlos Aguayo wrote: Thanks Colin, yeah that's what I figured, initially I thought that it would be a problem in the plugin given that it was only blocking Firefox and only in OS X (given that Chrome worked and also Firefox but under Linux). I started debugging and got all the way there. I doubt that it's a breakpoint or having to wait for a long time as I did leave the browser for a few minutes, there's no breakpoints and CPU is not peaking, so I'd think there's something else waiting. I'll follow your suggestion and check now the other side, but it's good to know that you haven't had an issue with FF and Mavericks as then that would sadly imply that there's something wrong with my computer :(. On Friday, November 8, 2013 9:20:10 PM UTC-5, Colin Alworth wrote: Line 155: ssize_t n = recv(sock, readBuf, BUF_SIZE, 0); That seems to say 'block until bytes are written by the other end of the socket', or in other words, wait until the JVM is ready to go. Are you sure that the IDE isn't paused on a breakpoint, or that you have waited long enough for the page to load? When the browser is in this state, try pausing the JVM to see what the dev mode thread is doing - I'm betting it is hard at work on something... but if it too is waiting for something, that could be a problem. But the recv call is *supposed* to block, at least until dev mode has finished running its not-yet-JS code. We've had no issues with Mavericks and latest FF in our projects fwiw, aside from the usual 'dev mode takes longer to do anything' fun. On Thursday, November 7, 2013 10:59:18 PM UTC-6, Carlos Aguayo wrote: It's getting stuck in line 155 in: https://gwt.googlesource.com/gwt-plugins/+/master/common/Socket.cpp On Thursday, November 7, 2013 7:32:28 PM UTC-5, Carlos Aguayo wrote: I'm started to have issues when trying to use DevMode with Firefox in OS X and the only thing new is that I upgraded to Mavericks. Here's what I see: I create a GWT sample app (the default one that comes with the Eclipse GWT plugin), I launch dev mode and try to access it with Firefox, as soon as I paste the address, the browser freezes. It stays frozen until I stop development mode, once I do that, Firefox comes back to life. Using Chrome is fine. I also have a VM setup with Linux and Firefox, if I try to debug through that Firefox, everything works as well. I tried to see if there was any sort of deadlock in the devmode plugin by using jconsole but it says that there's no deadlock. I have already ensured that Firefox is clean by doing a Reset Firefox Apparently the only thing that fixes this issue is by creating a new profile. After I create a new profile, I only install the GWT plugin and works for a few days, then it freezes again. I don't install anything else in Firefox. I have tried different versions of Firefox (21, 24 and 25) and I see the same behavior in all of them. I was wondering if anyone else could be seeing something similar and/or would have any suggestions as to how to debug the GWT extension to try to figure out what's going on? -- 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: Testing w/Selenium against app running in Eclipse demands Firefox Development Mode Plugin
By default, Selenium starts the browser with a fresh profile every time, which means that it has no plugins installed. On quitting, it deletes that profile again, to make sure that it won't slowly consume your disk. When you start the firefox driver instance, you can ask it to load profile details, including plugins. You can either create a new profile that only has this plugin added (to keep things simpler and avoid other plugin issues), or you can actually use your own default profile. http://steveliles.github.io/testing_gwt_apps_in_dev_mode_with_webdriver.html documents using your own profile, but this requires already having a firefox profile set up locally with dev mode, which may not be ideal for using other test machines to verify your app. https://groups.google.com/d/topic/webdriver/xPDudSnAxwo/discussion documents doing this the other way around, using the default of a fresh profile (no history, no cache, no plugins, etc), and adding the gwt dev mode plugin. On Wednesday, November 6, 2013 2:37:17 PM UTC-6, Jeff Levene wrote: Using GWT 2.4.0, Eclipse Kepler, Firefox 25.0, JDK 1.7.0_40, TestNG 6.8.5 When I run my test suite against the GWT app running on a Tomcat server, all is well. When I try to run it against a local copy running in Eclipse, instead of bringing up my application, Firefox gives me: Development Mode requires the GWT Developer Plugin with a badge to click on to download the plugin. It does this no matter how many times I have downloaded and installed the plugin and re-started Firefox. Ideas? -- 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: [gwt-contrib] GWT 2.6 and Java 6
Thanks for the clarification, I'll take a quick stab to see if I can make that change on my own. On Nov 9, 2013 5:40 PM, Roberto Lublinerman rlu...@google.com wrote: You are right, there should be an extra option -sourceLevel auto and that should be the default for devmode. On Nov 8, 2013, at 17:47, Colin Alworth niloc...@gmail.com wrote: Thanks Roberto, I'll give that a shot. I normally work with Java 7, but we want our code to work with anyone who chooses to use Java 6 as well - and I surmised that GWT had the same goal. Would it make sense to consider a warning indicating that the flag is needed with Java 6, or auto-detecting that Java 6 is running so a JavaScriptObject$ compiled for 7 can't possibly work? On Friday, November 8, 2013 6:01:40 PM UTC-6, Roberto Lublinerman wrote: You should be able to invoke devmode with -sourceLevel 6. Roberto Lublinerman | Software Engineer | rlu...@google.com | 408-500-9148 On Fri, Nov 8, 2013 at 3:31 PM, Colin Alworth nilo...@gmail.com wrote: I'm not yet convinced that this isn't either a) a workspace issue or b) a decision the community reached and I missed, but I figured I should stick it out there and see if someone can correct me. I've just brought our project up to date with GWT 2.6.0-rc1 from maven, and I can verify that the class files have magic number 50.0 set on them, indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc behaves as expected, but I can't run dev mode. The error I get usually goes a little like this: ERROR: Unable to initialize static dispatcher java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220) The magic number 51.0 indicates Java7 - how is it that while I'm running Java 6, I am generating Java 7-only classes? My working theory is that since we moved some internals to be Java 7 capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or a related commit), it was set as the default. My question: do we intend to require Java 7 for dev mode (and therefore also GWTTestCase run in dev mode), but allow Java 6 for essentially everything else? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Firefox in OS X freezes in DevMode.
Line 155: ssize_t n = recv(sock, readBuf, BUF_SIZE, 0); That seems to say 'block until bytes are written by the other end of the socket', or in other words, wait until the JVM is ready to go. Are you sure that the IDE isn't paused on a breakpoint, or that you have waited long enough for the page to load? When the browser is in this state, try pausing the JVM to see what the dev mode thread is doing - I'm betting it is hard at work on something... but if it too is waiting for something, that could be a problem. But the recv call is *supposed* to block, at least until dev mode has finished running its not-yet-JS code. We've had no issues with Mavericks and latest FF in our projects fwiw, aside from the usual 'dev mode takes longer to do anything' fun. On Thursday, November 7, 2013 10:59:18 PM UTC-6, Carlos Aguayo wrote: It's getting stuck in line 155 in: https://gwt.googlesource.com/gwt-plugins/+/master/common/Socket.cpp On Thursday, November 7, 2013 7:32:28 PM UTC-5, Carlos Aguayo wrote: I'm started to have issues when trying to use DevMode with Firefox in OS X and the only thing new is that I upgraded to Mavericks. Here's what I see: I create a GWT sample app (the default one that comes with the Eclipse GWT plugin), I launch dev mode and try to access it with Firefox, as soon as I paste the address, the browser freezes. It stays frozen until I stop development mode, once I do that, Firefox comes back to life. Using Chrome is fine. I also have a VM setup with Linux and Firefox, if I try to debug through that Firefox, everything works as well. I tried to see if there was any sort of deadlock in the devmode plugin by using jconsole but it says that there's no deadlock. I have already ensured that Firefox is clean by doing a Reset Firefox Apparently the only thing that fixes this issue is by creating a new profile. After I create a new profile, I only install the GWT plugin and works for a few days, then it freezes again. I don't install anything else in Firefox. I have tried different versions of Firefox (21, 24 and 25) and I see the same behavior in all of them. I was wondering if anyone else could be seeing something similar and/or would have any suggestions as to how to debug the GWT extension to try to figure out what's going on? -- 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.
[gwt-contrib] GWT 2.6 and Java 6
I'm not yet convinced that this isn't either a) a workspace issue or b) a decision the community reached and I missed, but I figured I should stick it out there and see if someone can correct me. I've just brought our project up to date with GWT 2.6.0-rc1 from maven, and I can verify that the class files have magic number 50.0 set on them, indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc behaves as expected, but I can't run dev mode. The error I get usually goes a little like this: ERROR: Unable to initialize static dispatcher java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220) The magic number 51.0 indicates Java7 - how is it that while I'm running Java 6, I am generating Java 7-only classes? My working theory is that since we moved some internals to be Java 7 capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or a related commit), it was set as the default. My question: do we intend to require Java 7 for dev mode (and therefore also GWTTestCase run in dev mode), but allow Java 6 for essentially everything else? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT 2.6 and Java 6
Thanks Roberto, I'll give that a shot. I normally work with Java 7, but we want our code to work with anyone who chooses to use Java 6 as well - and I surmised that GWT had the same goal. Would it make sense to consider a warning indicating that the flag is needed with Java 6, or auto-detecting that Java 6 is running so a JavaScriptObject$ compiled for 7 can't possibly work? On Friday, November 8, 2013 6:01:40 PM UTC-6, Roberto Lublinerman wrote: You should be able to invoke devmode with -sourceLevel 6. Roberto Lublinerman | Software Engineer | rlu...@google.com javascript: | 408-500-9148 On Fri, Nov 8, 2013 at 3:31 PM, Colin Alworth nilo...@gmail.comjavascript: wrote: I'm not yet convinced that this isn't either a) a workspace issue or b) a decision the community reached and I missed, but I figured I should stick it out there and see if someone can correct me. I've just brought our project up to date with GWT 2.6.0-rc1 from maven, and I can verify that the class files have magic number 50.0 set on them, indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc behaves as expected, but I can't run dev mode. The error I get usually goes a little like this: ERROR: Unable to initialize static dispatcher java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.lang.ClassLoader.defineClass(ClassLoader.java:471) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220) The magic number 51.0 indicates Java7 - how is it that while I'm running Java 6, I am generating Java 7-only classes? My working theory is that since we moved some internals to be Java 7 capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or a related commit), it was set as the default. My question: do we intend to require Java 7 for dev mode (and therefore also GWTTestCase run in dev mode), but allow Java 6 for essentially everything else? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today
Just moved to eclipse to verify a possible issue with the snapshot (nope, bug was in my code), and eclipse seems to do okay with finding each artifact in its own snapshot. Can you ping the list when you push a new set of snapshots? -Colin On Nov 5, 2013 7:55 PM, Matthew Dempsky mdemp...@google.com wrote: Thanks for testing, Colin! I'll try another push tonight using your scripts. On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth niloc...@gmail.com wrote: It looks like while I can get maven from the command line to get along with that repo, IntelliJ isn't having it - it is getting confused by the fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a sources jar and a pom, no actual jar with compiled code in it. The -1 jar is only the compiled code, the -2 is only javadoc, and the -3 is, as mentioned, sources. The maven/push-gwt.sh patch I put up should resolve this - for now this setup is good for maven builds, but not for IDEs that expect to have sources and javadocs available in the 'same' snapshot. On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote: In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to https://oss.sonatype.org/content/repositories/google-snapshots/. On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky mdem...@google.comwrote: As promised, I created the release/2.6 branch for tracking development towards 2.6. At this point, development can continue on master towards the next release. If you think a change should be made for 2.6, please propose it against master, and then notify me to cherry pick it onto release/2.6. Setting up the 2.6 release branch took longer than expected due to some last minute changes and technical issues. I plan to finish preparing the 2.6rc1 snapshot tomorrow morning, and push them out. I'll send an announcement when that's ready. Thanks for your patience and sorry for the slight delay. On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky mdem...@google.comwrote: As a reminder, I'm going to create the GWT 2.6 branch later today and prepare a 2.6rc1 snapshot. There's still some time to propose and submit patches, but it's down to hours remaining now. Don't fret if you miss the deadline: there will be more releases in the future! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today
:2.6.0-SNAPSHOT/maven-metadata.xml from/to sonatype ( https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed to transfer file: https://oss.sonatype.org/service/local/staging/deploy/maven2//com/google/gwt/gwt-dev/2.6.0-SNAPSHOT/maven-metadata.xml. Return code is: 400 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.126s [INFO] Finished at: Wed Nov 06 15:47:54 PST 2013 [INFO] Final Memory: 8M/112M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on project standalone-pom: Failed to retrieve remote metadata com.google.gwt:gwt-dev:2.6.0-SNAPSHOT/maven-metadata.xml: Could not transfer metadata com.google.gwt:gwt-dev:2.6.0-SNAPSHOT/maven-metadata.xml from/to sonatype ( https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed to transfer file: https://oss.sonatype.org/service/local/staging/deploy/maven2//com/google/gwt/gwt-dev/2.6.0-SNAPSHOT/maven-metadata.xml. Return code is: 400 - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException Error while deploying, ignore errors? (y/N): I'm going to root cause what's going on, but maybe you have an idea what's going on? On Wed, Nov 6, 2013 at 1:49 PM, Colin Alworth niloc...@gmail.comwrote: Just moved to eclipse to verify a possible issue with the snapshot (nope, bug was in my code), and eclipse seems to do okay with finding each artifact in its own snapshot. Can you ping the list when you push a new set of snapshots? -Colin On Nov 5, 2013 7:55 PM, Matthew Dempsky mdemp...@google.com wrote: Thanks for testing, Colin! I'll try another push tonight using your scripts. On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth niloc...@gmail.comwrote: It looks like while I can get maven from the command line to get along with that repo, IntelliJ isn't having it - it is getting confused by the fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a sources jar and a pom, no actual jar with compiled code in it. The -1 jar is only the compiled code, the -2 is only javadoc, and the -3 is, as mentioned, sources. The maven/push-gwt.sh patch I put up should resolve this - for now this setup is good for maven builds, but not for IDEs that expect to have sources and javadocs available in the 'same' snapshot. On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote: In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to https://oss.sonatype.org/ content/repositories/google-snapshots/. On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky mdem...@google.com wrote: As promised, I created the release/2.6 branch for tracking development towards 2.6. At this point, development can continue on master towards the next release. If you think a change should be made for 2.6, please propose it against master, and then notify me to cherry pick it onto release/2.6. Setting up the 2.6 release branch took longer than expected due to some last minute changes and technical issues. I plan to finish preparing the 2.6rc1 snapshot tomorrow morning, and push them out. I'll send an announcement when that's ready. Thanks for your patience and sorry for the slight delay. On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky mdem...@google.com wrote: As a reminder, I'm going to create the GWT 2.6 branch later today and prepare a 2.6rc1 snapshot. There's still some time to propose and submit patches, but it's down to hours remaining now. Don't fret if you miss the deadline: there will be more releases in the future! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit
Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today
Can you clarify about 2.6.0-rc1? Are we pushing the current build as 2.6.0-rc1 to maven central? I don't yet see 2.6.0-rc1 in central, nor in the google-snapshots. A key detail about maven is that once a release is pushed with a particular version, it can't be unpushed, released is released. Snapshots are the other way around, you are allowed to update snapshots, as well as remove stale ones. On the plus side, the -SNAPSHOT build looks to be working great from my testing. On Wed, Nov 6, 2013 at 7:07 PM, Matthew Dempsky mdemp...@google.com wrote: On Wed, Nov 6, 2013 at 4:54 PM, Colin Alworth niloc...@gmail.com wrote: My vote is 2.6.0-SNAPSHOT and 2.6.0-rc1, in case we need a bug fix release... Being consistent with snapshot versions lets maven users update to the new nightly without any config file changes. SGTM; rebuilt as 2.6.0-rc1 and pushed to google-snapshots as 2.6.0-SNAPSHOT. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today
Email is almost fast enough to avoid this confusion - disregard my questions, looks like I've already got my answer! On Wed, Nov 6, 2013 at 11:02 PM, Matthew Dempsky mdemp...@google.comwrote: gwt-2.6.0-rc1.zip download: https://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-2.6.0-rc1.zip (Next up the Maven 2.6.0-rc1 artifacts.) On Wed, Nov 6, 2013 at 5:07 PM, Matthew Dempsky mdemp...@google.comwrote: On Wed, Nov 6, 2013 at 4:54 PM, Colin Alworth niloc...@gmail.com wrote: My vote is 2.6.0-SNAPSHOT and 2.6.0-rc1, in case we need a bug fix release... Being consistent with snapshot versions lets maven users update to the new nightly without any config file changes. SGTM; rebuilt as 2.6.0-rc1 and pushed to google-snapshots as 2.6.0-SNAPSHOT. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Reminder: Branching GWT 2.6 later today
It looks like while I can get maven from the command line to get along with that repo, IntelliJ isn't having it - it is getting confused by the fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a sources jar and a pom, no actual jar with compiled code in it. The -1 jar is only the compiled code, the -2 is only javadoc, and the -3 is, as mentioned, sources. The maven/push-gwt.sh patch I put up should resolve this - for now this setup is good for maven builds, but not for IDEs that expect to have sources and javadocs available in the 'same' snapshot. On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote: In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to https://oss.sonatype.org/content/repositories/google-snapshots/. On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky mdem...@google.comjavascript: wrote: As promised, I created the release/2.6 branch for tracking development towards 2.6. At this point, development can continue on master towards the next release. If you think a change should be made for 2.6, please propose it against master, and then notify me to cherry pick it onto release/2.6. Setting up the 2.6 release branch took longer than expected due to some last minute changes and technical issues. I plan to finish preparing the 2.6rc1 snapshot tomorrow morning, and push them out. I'll send an announcement when that's ready. Thanks for your patience and sorry for the slight delay. On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky mdem...@google.comjavascript: wrote: As a reminder, I'm going to create the GWT 2.6 branch later today and prepare a 2.6rc1 snapshot. There's still some time to propose and submit patches, but it's down to hours remaining now. Don't fret if you miss the deadline: there will be more releases in the future! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: undefined.cache.js when starting GWT app in web mode?
If you compile in PRETTY instead of DETAILED, it won't intern those
strings, but still will leave the output mostly readable (just no packages).
Without seeing the rest of the structure of the module files, it is hard to
speculate, but we're using more or less the same idea successfully, though
we're doing it backward. Inside of GXT we defined a broader set of user
agents, and then distill down to just the 6 (as of gwt 2.4, 2.5)
permutations that GWT itself supports. This takes over GWT's own
property-provider and uses ours instead. The chief difference is that
user.agent already has a property-provider, but we're trying to instruct it
which property to use instead.
In lieu of your full module/setup, here's a quick sample I threw together
that seems to do more or less what you are requiring, and seems to fail in
the same way:
module rename-to=test
inherits name=com.google.gwt.core.Core /
define-property name=foo value=a, b, c /
define-property name=bar value=x, y /
set-property name=bar value=x
any
when-property-is name=foo value=a /
when-property-is name=foo value=b /
/any
/set-property
set-property name=bar value=y
when-property-is name=foo value=c /
/set-property
property-provider name=foo![CDATA[return
window.location.query;]]/property-provider
entry-point class=path.to.client.Test /
/module
public class Test implements EntryPoint {
@Override
public native void onModuleLoad() /*-{
console console.log console.log('loaded successfully');
}-*/;
}
The foo provider is compiled out as expected:
providers['foo'] = function(){
return window.location.search[1];
}
but bar gets a default handler, one that clearly doesn't make sense here:
providers['bar'] = function(){
return __gwt_getMetaProperty('bar');
}
By adding set-property name=bar value=x /, the code works, but it
doesn't correctly select a y value when it should (the permutation selector
code is just gone).
Through any case where bar is present in the selector, I continue to see
this block:
unflattenKeylistIntoAnswers(['x', 'a', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['x', 'b', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['y', 'c', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['x', 'a', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
unflattenKeylistIntoAnswers(['x', 'b', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
unflattenKeylistIntoAnswers(['y', 'c', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
//etc
demonstrating that the 'collapsing' work is being done - there is never a
x-y, nor a y-a/y-b line. From this, I'm suspecting that the design of this
feature is to minimize permutations, not remove selector scripts altogether
- from
http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties,
This alternateFeatures property is called *derived* because its value can
be determined solely from other deferred-binding properties. There is never
a need to execute a property provider for a derived property. Moreover,
derived properties do not expand the permutation matrix and have no
deployment cost.
Misleading, not not actually inaccurate - there *isn't* a need to execute
the property provider, but the current implementation seems to still do it
anyway, and fails when it cannot be done. The only advantage we are getting
out of conditional properties is the minimized set of permutations.
On Monday, October 28, 2013 11:23:02 AM UTC-5, Ed wrote:
I didn't think it would help, but I just added a default browser.engine
property to the BrowserEngine.gwt.xml file, just below the
define-property...:
set-property name=browser.engine value=webkit / !-- provide a
default as last resort --
Strange enough this does help, as it does starts now.
The code to determine the strong name has changed to:
strongName =
answers[computePropValue($intern_47)][computePropValue($intern_58)];
As you can see the browser.engine property has been removed as argument.
Before it was:
strongName = answers[computePropValue($intern_47)][computePropValue($
intern_48)][computePropValue($intern_59)];
Why this difference?
btw: it seems to work in both chrome/FF.
--
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: Thoughts on GWT 3.0 re: Java 8 and IE 8/9
We've found experimentally that the meta tag has no effect on IE8 when in
intranet mode. We've further found that it does seem to respect the http
header, which could be set in a filter like this:
public class LatestIEFilter implements Filter {
@Override
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
((HttpServletResponse)resp).setHeader(X-UA-Compatible, IE=latest);
chain.doFilter(req, resp);
}
//...
}
rant
Since IE8-pretending-to-be-IE7 behaves like neither IE8 nor IE7 (at least
not completely), I generally maintain that code trying to fit either one
shouldn't be expected to work. IIRC, IE8-pretending-to-be-IE7 can't be
distinguished from IE7, so the only way to make a library/application work
in a so-called compatibility mode is to custom tailor it for that mode, and
ignore the 'real' browser modes.
/rant
On Monday, October 28, 2013 12:00:57 PM UTC-5, Thomas Broyer wrote:
On Monday, October 28, 2013 4:22:29 PM UTC+1, Chak Lai wrote:
If IE7support is removed from GWT, will GWT run correctly on IE in
Intranet? (IE will default to IE7 Browser mode for Intranet Website)
Include the correct meta http-equiv=X-UA-Compat in the HTML?
A Google search led me to
http://tesmond.blogspot.fr/2011/10/ie9-intranet-compatibility-mode-in.html
(which
also links to
http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx
)
Otherwise, well, just don't upgrade to a newer GWT: if you live in the
past, don't use cutting-edge tools. (this is not a criticism)
--
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: undefined.cache.js when starting GWT app in web mode?
Looks like my sample may have been too simplistic - upon re-reading
http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties it
looks like they do indeed suggest using a default as the 'correct' way to
do things:
!-- Provide a default --
set-property name=alternateFeatures value=false /
I'll try to build a more complex test case that actually uses the
properties defined, just in case the compiler is getting to clever for me.
On Monday, October 28, 2013 12:45:45 PM UTC-5, Colin Alworth wrote:
If you compile in PRETTY instead of DETAILED, it won't intern those
strings, but still will leave the output mostly readable (just no packages).
Without seeing the rest of the structure of the module files, it is hard
to speculate, but we're using more or less the same idea successfully,
though we're doing it backward. Inside of GXT we defined a broader set of
user agents, and then distill down to just the 6 (as of gwt 2.4, 2.5)
permutations that GWT itself supports. This takes over GWT's own
property-provider and uses ours instead. The chief difference is that
user.agent already has a property-provider, but we're trying to instruct it
which property to use instead.
In lieu of your full module/setup, here's a quick sample I threw together
that seems to do more or less what you are requiring, and seems to fail in
the same way:
module rename-to=test
inherits name=com.google.gwt.core.Core /
define-property name=foo value=a, b, c /
define-property name=bar value=x, y /
set-property name=bar value=x
any
when-property-is name=foo value=a /
when-property-is name=foo value=b /
/any
/set-property
set-property name=bar value=y
when-property-is name=foo value=c /
/set-property
property-provider name=foo![CDATA[return
window.location.query;]]/property-provider
entry-point class=path.to.client.Test /
/module
public class Test implements EntryPoint {
@Override
public native void onModuleLoad() /*-{
console console.log console.log('loaded successfully');
}-*/;
}
The foo provider is compiled out as expected:
providers['foo'] = function(){
return window.location.search[1];
}
but bar gets a default handler, one that clearly doesn't make sense here:
providers['bar'] = function(){
return __gwt_getMetaProperty('bar');
}
By adding set-property name=bar value=x /, the code works, but it
doesn't correctly select a y value when it should (the permutation selector
code is just gone).
Through any case where bar is present in the selector, I continue to see
this block:
unflattenKeylistIntoAnswers(['x', 'a', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['x', 'b', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['y', 'c', 'gecko1_8'],
'20D7C847BEB9A7D69CDF024B3FA7AE54');
unflattenKeylistIntoAnswers(['x', 'a', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
unflattenKeylistIntoAnswers(['x', 'b', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
unflattenKeylistIntoAnswers(['y', 'c', 'ie9'],
'2F5083A323F0E99E2BC83F08F6D97D35');
//etc
demonstrating that the 'collapsing' work is being done - there is never a
x-y, nor a y-a/y-b line. From this, I'm suspecting that the design of this
feature is to minimize permutations, not remove selector scripts altogether
- from
http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties,
This alternateFeatures property is called *derived* because its value
can be determined solely from other deferred-binding properties. There is
never a need to execute a property provider for a derived property.
Moreover, derived properties do not expand the permutation matrix and have
no deployment cost.
Misleading, not not actually inaccurate - there *isn't* a need to execute
the property provider, but the current implementation seems to still do it
anyway, and fails when it cannot be done. The only advantage we are getting
out of conditional properties is the minimized set of permutations.
On Monday, October 28, 2013 11:23:02 AM UTC-5, Ed wrote:
I didn't think it would help, but I just added a default browser.engine
property to the BrowserEngine.gwt.xml file, just below the
define-property...:
set-property name=browser.engine value=webkit / !-- provide a
default as last resort --
Strange enough this does help, as it does starts now.
The code to determine the strong name has changed to:
strongName =
answers[computePropValue($intern_47)][computePropValue($intern_58)];
As you can see the browser.engine property has been removed as
argument. Before it was:
strongName = answers[computePropValue($intern_47)][computePropValue($
intern_48)][computePropValue($intern_59)];
Why this difference?
btw: it seems to work in both chrome/FF.
--
You received this message because you are subscribed
Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9
Chak, take a look again at my post - while the meta tag definitely does not work to tell IE8 to behave when in intranet mode, loading the exact same html content and sending the same ua-compat details over a HTTP header *does* solve this. On Monday, October 28, 2013 3:08:47 PM UTC-5, Chak Lai wrote: On Monday, October 28, 2013 3:49:19 PM UTC-4, Jens wrote: In Intranet environment, that META tag can only change IE Document Mode (such as how IE layout the web page), but it cannot change IE Browser Mode (such as IE's JavaScript Engine). It is because the Browser Mode is loaded (Intranet is detected) before IE parse the HTML. Even with the meta http-equiv=X-UA-Compatible content=IE=edge,chrome=1 tag, in the Intranet environment IE 9 can display HTML5 sites in appearance only, but using IE 7's JavaScript engine, which does not support HTML5 feature like canvas... etc. I guess you have to uncheck the checkbox Display intranet sites in compatibility view in IE's compatibility view settings. -- J. My concern is even if the users are using IE9 or IE10, in Intranet the application can be broken because IE7 Browser Mode is being used, and the users or developers may not aware of what is going on. P.S: In my opinion, it is great for GWT moving forward, and personally I hate dealing with IE. However, just heads-up for those who are stuck with Intranet + IE. -- 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.
[gwt-contrib] Re: Building Elemental fails
I can't reproduce this, we're also running ant clean elemental dist on our
teamcity build. We're also running ubuntu 12, python 2.7.3. Last confirmed
building as of 0d6a865556ca56840114e8397a1f2be522e83361 (current HEAD).
On Monday, October 28, 2013 5:43:04 AM UTC-5, Jens wrote:
I just tried to add Elemental to our GWT trunk builds and thus changed
ant clean dist to ant clean elemental dist and now always getting the
following build error:
generate:
[exec] Traceback (most recent call last):
[exec] File idl/scripts/elemental_fremontcutbuilder.py, line 217,
in module
[exec] sys.exit(main())
[exec] File idl/scripts/elemental_fremontcutbuilder.py, line 214,
in main
[exec] return build_database(idl_files, database_dir)
[exec] File idl/scripts/elemental_fremontcutbuilder.py, line 139,
in build_database
[exec] builder.import_idl_file(file_name, webkit_options)
[exec] File
/var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/databasebuilder.py,
line 472, in import_idl_file
[exec] idl_file = self._load_idl_file(file_path, import_options)
[exec] File
/var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/databasebuilder.py,
line 86, in _load_idl_file
[exec] raise RuntimeError('Failed to load file %s: %s' %
(file_name, e))
[exec] RuntimeError: Failed to load file
idl/scripts/../third_party/WebCore/css/WebKitCSSRegionRule.idl: At line 1
offset 0: Expected module or interface or exception but found:
[exec] Traceback (most recent call last):
[exec] File idl/scripts/elementaldomgenerator.py, line 164, in
module
[exec] sys.exit(main())
[exec] File idl/scripts/elementaldomgenerator.py, line 155, in
main
[exec] database_dir, use_database_cache)
[exec] File idl/scripts/elementaldomgenerator.py, line 120, in
GenerateDOM
[exec] systems = systems)
[exec] File
/var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/elementalgenerator.py,
line 279, in Generate
[exec]
self.PopulateMixinBase(self._database.GetInterface('ElementalMixinBase'),
mixins)
[exec] File
/var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/database.py,
line 188, in GetInterface
[exec] raise RuntimeError('Interface %s is not loaded' %
interface_name)
[exec] RuntimeError: Interface ElementalMixinBase is not loaded
The build is executed by Jenkins on Ubuntu 12.04 with Python 2.7.3. I
tried the same on Mac OS (without Jenkins) and everything works as
expected. I have also created MD5 sums of WebKitCSSRegionRule.idl on
Ubuntu and Mac OS and both MD5 sums are the same.
Does anyone have an idea what can cause the above error?
-- J.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Building Elemental fails
Good thought, I tried that too to confirm that teamcity wasn't setting anything funny. Still passed, not sure what is up. Other details that may or may not help: $ java -version java version 1.6.0_35 Java(TM) SE Runtime Environment (build 1.6.0_35-b10) Java HotSpot(TM) Server VM (build 20.10-b01, mixed mode) $ ant -version Apache Ant(TM) version 1.8.2 compiled on December 3 2011 $ uname -a Linux ubuntu 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ python --version Python 2.7.3 On Monday, October 28, 2013 11:37:40 AM UTC-5, Jens wrote: Thx for checking it, Colin. Pretty strange that it doesn't work. The error also happens if I just execute ant on console directly on the server. -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Publish nighly snapshots of GWT builds to Maven
I've just put up a patch that seems to resolve a current issue in deploying snapshots to a maven repository: https://gwt-review.googlesource.com/5192 The basis of the problem requiring this patch is that maven (at least maven 3, possibly not maven 2) expects unique snapshots, and that each call to deploy:deploy-file or sign:sign-and-deploy uploads its artifact as a standalone object - when we call deploy three times (jar, sources, javadoc), the last one in is treated as the 'newest'. This doesn't happen for releases, as there can only be one release, while there can be several snapshots for a version. As noted, this patch does not resolve the issue locally - its my understanding that install:install-file would need to be used to make this work our locally, or else I'm just doing it wrong. The issue appears to be related to metadata not being updated correctly, but I didn't debug too extensively. I think that we can safely ignore local snapshots for the time being anyway - first, they didn't work before this patch, and second a user can either build from a snapshot server or can assign a non-snapshot version when installing locally and run it multiple times (pushing a non-snapshot version to a remote server would result in clients caching that result and not downloading it again). I'd appreciate any testing of this so that we can see about starting to put out snapshot builds on sonatype going forward. On Sunday, September 22, 2013 8:53:16 AM UTC-5, Thomas Broyer wrote: It should be relatively easy with the existing shell scripts; the major pain point would be securing the credentials. I think Sonatype can do app passwords. I can have a look at the scripts if needs be, as I think they've only been tested for local deployment or staging, and only for releases (not snapshots) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT Profiling and MemoryLeak suspections
Without specifics of what may be referencing those objects it is hard to say for sure, but memory details while running in dev mode will likely not reflect the compiled code. To properly test your memory patterns, compile to JavaScript with style PRETTY or DETAILED so you can read the code, and use a JavaScript memory profiler like Chrome's Inspector to hunt down any possible leaks. For your second question, ad you saying that setWidget(null) doesn't remove the child from the SimplePanel? Which field in SimplePanel is pointing at the old child? Widget.setWidget calls remove(this.widget) which should clear out the widget field as well as detach the dom element, so I'm not clear on how 'SimplePanel doesn't release inner widget'. That said, Dev Mode's performance and memory characteristics are not going to be exactly the same as compiled code, and compiled production code is what really needs to be correct. On Monday, October 21, 2013 3:46:14 AM UTC-5, Hakan Junior wrote: Hi all, I want to check my application for memory leaks. Can you help me? I installed JProfiler 8 and attached it to debug moded jetty (ran from eclipse plugin) and checked the live heap objects. Every created component exists in the heap and never gc'ed until page refresh. When i looked at the objects i cant see a circular reference (incoming refs) except some com.gwt... classes in fields named target and/or source. Is that normal in DebugDevMode ran from Eclipse since not translated to Javascript? One more related important question is; I have a composite widget named Form. Its a composition of objects and handlers. It has 3 textboxes and 1 button defined as global/field in class and created in class constructor and put to a SimplePanel area via Grid. Button has an anonymously implemented click handler. In JProfiler the anonymously implemented class instance exists in the heap and never gc'ed (same as above case, DebugDevMode from Eclipse). And the button and the composite instances seem to be cycle referenced because of SimplePanel doesnt release inner widget. So i invoked SimplePanel object's setWidget(null) on onUnload but didnt remove buttons click handler. At this point; Can i accept these as normal and wont worry about memory leak? or is that a really problem and i should nullify button,textboxes in the onUnload method? In anyway do i need to remove click handler from button? Thank you all. -- 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.
[gwt-contrib] Re: Where is gwt-customchecks.jar?
If only *all* of my changes were that easy to make... On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote: Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Bad news for GWT DevMode!
Amazingly, it still works great in the IE11 preview too! Only gotcha is that the missing plugin page thinks you are running firefox, so you need to manually grab the right copy of the IE plugin. On Tuesday, October 22, 2013 12:58:57 PM UTC-5, Brian Slesinsky wrote: I expect that by next summer devmode will *only* work in IE and perhaps an older version of Firefox. Oddly enough, the IE plugin has apparently worked for years with no complaints. (But the issue is that nobody currently on the team has ever built it.) - Brian On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer t.br...@gmail.comjavascript: wrote: I don't think any committer to the GWT project uses Windows (other than for testing, using VMs then), so it'd be either Firefox or Chrome (no other choice on Linux; and on OSX, Safari is no longer supported started with 5.1, and I don't think anyone uses OmniWeb or similar). Both work well. To answer the question about a “preferred browser”, I've been told that, on Windows, IE works best (is the fastest); that was a while back though, so things might have changed. On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote: IMO Firefox On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote: Just curious, is there a preferred browser for Classic DevMode? What do the cool kids use? :) On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote: Just saw this passing on Twitter: http://blog.chromium.** org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the browser. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Bad news for GWT DevMode!
I end up debugging IE in dev mode on a regular basis as well, though in a VM, through to my host OS's Eclipse or IntelliJ debugger. It is significantly slower than running the IDE and browser on the same OS, but it does let you set up your env once and debug multiple OSes whenever you like. On Mon, Oct 21, 2013 at 8:56 AM, Thomas Broyer t.bro...@gmail.com wrote: I don't think any committer to the GWT project uses Windows (other than for testing, using VMs then), so it'd be either Firefox or Chrome (no other choice on Linux; and on OSX, Safari is no longer supported started with 5.1, and I don't think anyone uses OmniWeb or similar). Both work well. To answer the question about a “preferred browser”, I've been told that, on Windows, IE works best (is the fastest); that was a while back though, so things might have changed. On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote: IMO Firefox On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote: Just curious, is there a preferred browser for Classic DevMode? What do the cool kids use? :) On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote: Just saw this passing on Twitter: http://blog.chromium.** org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the browser. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Reminder: GWT 2.6 feature complete is Nov 4
Patrick, looking at these, only two appear to have code reviews, and both are in the pre-git system. Gerrit, the current system, needs a CLA before it allows changes, to make sure that there are no copyright/licensing issues with contributions, and makes history/change management a little easier. Can you migrate those to Gerrit so they can be reviewed and merged? Link back to the original so any discussion there can be read and taken into account by future reviewers. On Friday, October 18, 2013 7:18:40 AM UTC-5, Patrick Tucker wrote: I really would like to see some of these make the cut. Most of the which are trivial fixes, some have patches proposed. title set on parent TreeItem appears also on its children http://code.google.com/p/google-web-toolkit/issues/detail?id=1393 HeaderPanel setHeaderWidget is broken http://code.google.com/p/google-web-toolkit/issues/detail?id=7037 BorderStyle enum is missing values http://code.google.com/p/google-web-toolkit/issues/detail?id=8071 Inconsistent TextArea border-top style http://code.google.com/p/google-web-toolkit/issues/detail?id=8176 Vertical MenuBar popup is always left aligned even if there is not enough right-space to do so. http://code.google.com/p/google-web-toolkit/issues/detail?id=3888 Add max-height and max-width support to Style http://code.google.com/p/google-web-toolkit/issues/detail?id=7905 I don't necessarily care about this one but it is just a documentation fix... Documentation for TabBar doesn't list gwt-TabBarItem-disabled *http://code.google.com/p/google-web-toolkit/issues/detail?id=4050*http://code.google.com/p/google-web-toolkit/issues/detail?id=4050 On Thursday, October 17, 2013 1:22:56 PM UTC-4, Matthew Dempsky wrote: Hi all, Just writing to remind everyone that the GWT 2.6 feature complete deadline is November 4th. On that day I'll fork the GWT 2.6 release branch, and I'll only approve patches for release critical bug fixes. The GWT 2.6 Release Planhttps://docs.google.com/a/gwtproject.org/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit# contains the handful of outstanding issues that I know we still want to get in for 2.6, and I'll be following up with people to try to make sure they're merged in time. If there are other features you think should be included but aren't listed, please speak up now so I can add them and track their progress. Thanks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Where is gwt-customchecks.jar?
Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Non-client apis and breaking changes
Just wandered by https://gwt-review.googlesource.com/#/c/1040/ and noticed that with this change, any downstream generator/linker using the static helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the other discussions going on about JRE and browser support, perhaps we could discuss something policy-like around 'internal' code like this? If the policy that internal public methods are not actually for public consumption, or subject to breakage across minor releases, we should note that somewhere to keep people away. My inclination is that we want to encourage downstream code to use utility methods like this rather than copying them into their own projects. And again on the side of discouraging use of code like this, how far and wide can public code be expected to be 'usable by downstream'? The com.google.gwt.editor.rebind.model.ModelUtils class is very handy for getting specifics about generic types, but from its package it is clearly part of editor so could change with modifications to that framework, whereas Name and StringKey seem to be in the relatively 'safe' package of com.google.gwt.dev.util with other benign classes like Util. Thoughts? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] gwtproject.org javadoc missing files
According to the the gwt-site git repo (at https://gwt.googlesource.com/gwt-site/+/master/src/main/site/javadoc/latest), the package-list file is present, but it can't be downloaded from http://www.gwtproject.org/javadoc/latest/package-list. It *is* still available from http://google-web-toolkit.googlecode.com/svn/javadoc/latest/package-list. This file is useful for projects that are building javadoc that should link up to GWT itself - without it, the javadoc tool apparently doesn't link to referenced classes in GWT. I'm not seeing anything useful in terms of a web.xml file or a servlet/filter/htaccess that can be customized to correct for this in the git repo, so I'm assuming that this is a server configuration change that needs to be made. Can someone confirm that, or point me in the right direction for a change I can make as a contributor? Thanks, Colin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Build failures after deprecated tree/treeitem methods removed
It looks like a recent commit that removed some deprecated methods may not have gone far enough, as there is still code that makes use of those methods - the https://gwt.googlesource.com/gwt/+/f9630059081921b195ee4f7014e1a78c4b570f79 commit dropped several methods from Tree and TreeItem, but the 'json' sample used those methods, so our nightly builds are seeing failures. Source file that continues to use removed addItem methods: https://gwt.googlesource.com/gwt/+/master/samples/json/src/com/google/gwt/sample/json/client/JSON.java Build log errors: compile: [mkdir] Created dir: /Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes [gwt.javac] Compiling 1 source file to /Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes [gwt.javac] /Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:132: error: no suitable method found for addItem(String) [gwt.javac] TreeItem child = treeItem.addItem(getChildText([ [gwt.javac] ^ [gwt.javac] method TreeItem.addItem(Widget) is not applicable [gwt.javac] (actual argument String cannot be converted to Widget by method invocation conversion) [gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to IsTreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(TreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to TreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable [gwt.javac] (actual argument String cannot be converted to SafeHtml by method invocation conversion) [gwt.javac] /Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:139: error: no suitable method found for addItem(String) [gwt.javac] TreeItem child = treeItem.addItem(getChildText(key)); [gwt.javac] ^ [gwt.javac] method TreeItem.addItem(Widget) is not applicable [gwt.javac] (actual argument String cannot be converted to Widget by method invocation conversion) [gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to IsTreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(TreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to TreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable [gwt.javac] (actual argument String cannot be converted to SafeHtml by method invocation conversion) [gwt.javac] /Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:144: error: no suitable method found for addItem(String) [gwt.javac] treeItem.addItem(jsonString.stringValue()); [gwt.javac] ^ [gwt.javac] method TreeItem.addItem(Widget) is not applicable [gwt.javac] (actual argument String cannot be converted to Widget by method invocation conversion) [gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to IsTreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(TreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to TreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable [gwt.javac] (actual argument String cannot be converted to SafeHtml by method invocation conversion) [gwt.javac] /Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:147: error: no suitable method found for addItem(String) [gwt.javac] treeItem.addItem(getChildText(jsonValue.toString())); [gwt.javac] ^ [gwt.javac] method TreeItem.addItem(Widget) is not applicable [gwt.javac] (actual argument String cannot be converted to Widget by method invocation conversion) [gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to IsTreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(TreeItem) is not applicable [gwt.javac] (actual argument String cannot be converted to TreeItem by method invocation conversion) [gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable [gwt.javac] (actual argument String cannot be converted to SafeHtml by method invocation conversion) [gwt.javac] /Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:154: error: no suitable method found for addItem(String) [gwt.javac] TreeItem treeItem = jsonTree.addItem(errorType); [gwt.javac] ^ [gwt.javac] method
Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?
Its never too late - I don't know how far Julien has gotten, but I've been distracted by other work, as well as trying to nail down conceptually where GSS meets ClientBundle. For my part, SASS or LESS are a major step down from what we already have - the purpose of GWT in general is to let you write maintainable code that compiles to well-performing code, but not expose features that will perform badly (consider the lack of java.text, reflection support). The scoping feature that sass/less/compass has (allowing you to nest rules within other rules) makes for much longer selectors in the compiled out code, which equates pretty directly to worse performance (longer selectors take longer to find/track what they apply to). In contrast, Closure Stylesheets gives us the same sorts of variables, mixins, and @if syntax, but puts as much of this work on the compiler rather than adding more classes at runtime. It is a little more limited (and I'm not sure how we can even achieve things such as @def and @eval... which current CssResource has), but those limitations seem designed to provide better runtime performance. On a different note, less/sass are implemented in Ruby, not Java, so either they must be made to work in JRuby or we'd need to require an existing Ruby installation. OOCSS could be worth looking at - I don't know anything about it yet but would be interested in learning. At a glance, it *appears* to be more of a philosophy about writing html/css and a single set of starting structural css, rather than a more 'useful' css language - do I have it right? Also, just as GssResource can be added as a new ResourcePrototype type, you could just as easily create a LessResource or OocssResource with its own generator to perform the required transformations. I hang out in ##gwt on freenode, and would love to talk more about this whole task with anyone who is interested, otherwise i'd be open for a hangout to chat too. On Wednesday, September 25, 2013 2:24:06 AM UTC-5, Samuel Schmid wrote: I'm a little bit late in this discoussion, i see there is a lot of work already on going. But +1 for this. SASS or LESS would be a big plus. For me I think supporting OOCSS is more important than supporting CSS3 without workarounds. Thank you guys! Sam On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote: Hello. How could I refuse? :) SGTM. We will of course, still have to maintain all of the GWT-isms. Actually, I've been wondering if we shoudn't just adopt LESS or SASS extensions too. Yes, please. Greetings, Michael -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Possible firefox leak fix
process? How far back in
time do we rebuild and test?
* How many auto-generated files (mostly .h from the idl, but also the
.dll/.dylib/etc) do we commit when such a change is made?
* Apparently plugins don't need to provide a disconnect() method, but if
any do, are we *sure* they are actually being called as expected? Or is
onUnload a long-lived typo?
Looking forward to discussing this here, in ##gwt on freenode, or on the
call tomorrow,
Colin
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
commit 6969765b5b60731f12ce529bbc6f730922b7e817
Author: Colin Alworth niloc...@gmail.com
Date: Tue Sep 24 18:29:13 2013 -0500
Initial work on supporting a disconnect message from the browser to close off the connection to the code server
diff --git a/xpcom/ExternalWrapper.cpp b/xpcom/ExternalWrapper.cpp
index ab0423e..f4d61cb 100644
--- a/xpcom/ExternalWrapper.cpp
+++ b/xpcom/ExternalWrapper.cpp
@@ -399,6 +399,13 @@ NS_IMETHODIMP ExternalWrapper::Connect(const nsACString suppliedUrl,
return NS_OK;
}
+NS_IMETHODIMP ExternalWrapper::Disconnect() {
+ Debug::log(Debug::Info) Disconnecting... Debug::flush;
+ sessionHandler.get()-disconnect();
+ Debug::log(Debug::Info) ...Disconnected Debug::flush;
+ return NS_OK;
+}
+
// nsISecurityCheckedComponent
static char* cloneAllAccess() {
static const char allAccess[] = allAccess;
@@ -422,7 +429,7 @@ NS_IMETHODIMP ExternalWrapper::CanCreateWrapper(const nsIID * iid,
NS_IMETHODIMP ExternalWrapper::CanCallMethod(const nsIID * iid,
const PRUnichar *methodName, char **_retval) {
Debug::log(Debug::Spam) ExternalWrapper::CanCallMethod Debug::flush;
- if (strEquals(methodName, connect) || strEquals(methodName, init)) {
+ if (strEquals(methodName, connect) || strEquals(methodName, init) || strEquals(methodName, disconnect)) {
*_retval = cloneAllAccess();
} else {
*_retval = nullptr;
diff --git a/xpcom/IOOPHM.idl b/xpcom/IOOPHM.idl
index 1aeea54..14e4d6f 100644
--- a/xpcom/IOOPHM.idl
+++ b/xpcom/IOOPHM.idl
@@ -8,4 +8,5 @@ interface IOOPHM : nsISupports
boolean init(in nsIDOMWindow window);
boolean connect(in ACString url, in ACString sessionKey, in ACString addr,
in ACString moduleName, in ACString hostedHtmlVersion);
+ void disconnect();
};
Re: [gwt-contrib] Possible firefox leak fix
The patch I provided only tweaks the normal source, and leaves the
generated sources and binaries alone - I think that is already what you are
after.
Note that this does *not* stop the leak by itself - we need to decide what
to do about hosted.html/devmode.js. One (ugly) option is to try to have the
ff plugin add an event handler to the window's close to call back to its
own disconnect? I think there are other ways we could think about doing
this as well, but changing hosted.html keeps it consistent across the board.
On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
Hi,
Wow, thanks for tracking this down! Could you send a patch that just
modifies the source (not worrying about the autogenerated files)? I will
rebuild them when I do the next release.
Usually I just leave the existing dll's alone and move forward; it's not
worth fixing older plugins. However, I believe Firefox 24 will be an ESR
release so I think it's worth rebuilding that version.
On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
I spent a little time this weekend learning how to build firefox plugins,
and a little time spilled out into this week, but I think I'm at a point
where I can share what I've done, what I'm seeing, and start asking for
help to finalize this (if it is as meaningful as I hope it is).
First, the issue itself: It looks like we're actually leaking on both
ends - that is, not just in the JVM, but in the browser itself. When Dev
Mode transfers control back to the browser itself, it runs
BrowserChannelServer.reactToMessages(). This listens at the open socket
between the browser's plugin and itself, and waits for the next byte to
float over the wire, meaning that the browser wants something. This waiting
specifically happens in Message.readMessageType, where we block on
stream.readByte(). Once a tab/window has been closed, the thread that is
actively watching that connection stays stuck in readByte(), waiting for
that next message to float over the wire.
My first thought was why can't we just ask if that socket is closed? -
well, the socket *isn't* closed, which means that the browser is leaking
the socket itself, along with whatever supporting objects were set up to
manage that socket. Note that this suggests a workaround to the leak - quit
and relaunch firefox, and since the socket will be forcibly closed then,
readByte() will throw a EOF exception, and reactToMessages will trip off a
RemoteDeathError (not ideal, but at least it just logs it and moves on,
finishing the leak off).
Next I dug into how to make the plugin actually disconnect when the page
was closed. I started this by finding exactly where the socket was opened
(common/HostChannel.{h|cpp}), then what creates HostChannel objects in the
firefox plugin. This turns out to be achieved in this line in
xpcom/ExternalWrapper.cpp (plus instructive comments):
// TODO(jat): leaks HostChannel -- need to save it in a session object
and
// return that so the host page can call a disconnect method on it at
unload
// time or when it gets GC'd.
HostChannel* channel = new HostChannel();
Okay, so at the time it was written, it was known that this leaks the
channel. This is where I started losing confidence, as it doesnt look like
it could be this easy... The next block actually opens the connection, and
passes it off to a FFSessionHandler instance, which is stored away in a
field:
Debug::log(Debug::Debugging) Connecting... Debug::flush;
if (!channel-connectToHost(hostPart.c_str(),
atoi(portPart.c_str( {
*_retval = false;
return NS_OK;
}
Debug::log(Debug::Debugging) ...Connected Debug::flush;
sessionHandler.reset(new FFSessionHandler(channel/*, ctx*/));
All this code is part of ExternalWrapper::Connect (note, defined twice
for varying ff versions), and since Connect is never invoked internally, it
was my assumption that I could build a ExternalWrapper::Disconnect that
simply unwound this channel:
NS_IMETHODIMP ExternalWrapper::Disconnect() {
Debug::log(Debug::Info) Disconnecting... Debug::flush;
sessionHandler.get()-disconnect();
Debug::log(Debug::Info) ...Disconnected Debug::flush;
return NS_OK;
}
That, combined with two other changes seems to expose this new function
to be called from in the browser and actually triggers the QUIT case in
reactToMessages - First, declare this new method in IOOPHM.idl, and second
tweak ExternalWrapper's CanCallMethod check to allow invoking disconnect
from within the browser. Actually building with the attached patch then
modifies several other files (more on that later).
Next, how to make disconnect() be invoked from within the browser - it is
already declared and invoked from within hosted.html and devmode.js, but it
seems to be in an invalid window callback:
window.onUnload = function
Re: [gwt-contrib] Possible firefox leak fix
Done, change is at https://gwt-review.googlesource.com/4680.
Concern about breaking WindowImpl#initWindowCloseHandler was my guess as
well - after connect() is called and the app starts up, the app has already
wired up its own close handler, so it is too late when connect is
successful to replace unload.
Both the standard WindowImpl and the IE specific one replace onunload and
call the old version, so provided those stay consistent with
hosted.html/devmode.js, this approach should be okay...
I'd love to get any independent verification on this as even being a viable
fix - I've only tried it in FF24/mac so far.
-Colin
On Tuesday, September 24, 2013 8:02:54 PM UTC-5, Brian Slesinsky wrote:
+cromwellian since he did unload support.
Oops, I see now that you attached it. Could you upload it to Gerrit?
I looked pretty hard for a reason why it's window.onUnload and not
window.onload and I can't find any. It dates back to 2010 at least and was
copied from hosted.html, whether deliberately I don't know.
One issue is that it's possible the app itself might want an onunload
handler. See
user/src/com/google/gwt/user/client/impl/WindowImpl.java line 32 where it
can install an onunload handler. It does preserve the old one but it still
seems kind of fragile to install one in the devmode.js. I wonder if there's
some way to detect the unload event in C++?
- Brian
On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
The patch I provided only tweaks the normal source, and leaves the
generated sources and binaries alone - I think that is already what you are
after.
Note that this does *not* stop the leak by itself - we need to decide
what to do about hosted.html/devmode.js. One (ugly) option is to try to
have the ff plugin add an event handler to the window's close to call back
to its own disconnect? I think there are other ways we could think about
doing this as well, but changing hosted.html keeps it consistent across the
board.
On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
Hi,
Wow, thanks for tracking this down! Could you send a patch that just
modifies the source (not worrying about the autogenerated files)? I will
rebuild them when I do the next release.
Usually I just leave the existing dll's alone and move forward; it's not
worth fixing older plugins. However, I believe Firefox 24 will be an ESR
release so I think it's worth rebuilding that version.
On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comwrote:
I spent a little time this weekend learning how to build firefox
plugins, and a little time spilled out into this week, but I think I'm at
a
point where I can share what I've done, what I'm seeing, and start asking
for help to finalize this (if it is as meaningful as I hope it is).
First, the issue itself: It looks like we're actually leaking on both
ends - that is, not just in the JVM, but in the browser itself. When Dev
Mode transfers control back to the browser itself, it runs
BrowserChannelServer.**reactToMessages(). This listens at the open
socket between the browser's plugin and itself, and waits for the next
byte
to float over the wire, meaning that the browser wants something. This
waiting specifically happens in Message.readMessageType, where we block on
stream.readByte(). Once a tab/window has been closed, the thread that is
actively watching that connection stays stuck in readByte(), waiting for
that next message to float over the wire.
My first thought was why can't we just ask if that socket is closed?
- well, the socket *isn't* closed, which means that the browser is leaking
the socket itself, along with whatever supporting objects were set up to
manage that socket. Note that this suggests a workaround to the leak -
quit
and relaunch firefox, and since the socket will be forcibly closed then,
readByte() will throw a EOF exception, and reactToMessages will trip off a
RemoteDeathError (not ideal, but at least it just logs it and moves on,
finishing the leak off).
Next I dug into how to make the plugin actually disconnect when the
page was closed. I started this by finding exactly where the socket was
opened (common/HostChannel.{h|cpp}), then what creates HostChannel objects
in the firefox plugin. This turns out to be achieved in this line in
xpcom/ExternalWrapper.cpp (plus instructive comments):
// TODO(jat): leaks HostChannel -- need to save it in a session
object and
// return that so the host page can call a disconnect method on it at
unload
// time or when it gets GC'd.
HostChannel* channel = new HostChannel();
Okay, so at the time it was written, it was known that this leaks the
channel. This is where I started losing confidence, as it doesnt look like
it could be this easy... The next block actually opens the connection, and
passes it off to a FFSessionHandler
Where is the New Remove Service Wizard with Eclipse 4.3/Google/GWT plugin?
I downloaded and upgrade the tool set to Eclipse4.3/Google/GWT plugin on Windows 8. All is good, except the GWT wizards that used to be on the top of the New menu are gone. What do I need to do to put them back? -- 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: GWT/LinkedIn Integration Sample Project with Scribe
I deployed it to Google App Engine here http://neptune-1.appspot.com/ Note the source code download doesn't have the App Engine artifacts and some changes with session handling required for App Engine deployment. -- 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.
GWT/LinkedIn Integration Sample Project with Scribe
A few years back, I did some exploration of using LinkedIn OAuth in GWT applications. I recently rewrite the sample app with the latest Scribe library by Fernandez Pablo (https://github.com/fernandezpablo85/scribe-java), and add a few more LinkedIn api calls. You should be able to use it as a starting point to add more advanced interactions with LinkedIn. The project source code can be downloaded from Google Code repo: https://code.google.com/p/gwt-cs/downloads/list. LinkedinFlows.zip is the code package. You will need to get your own LinkedIn Api key/secret, and download Scribe and Simple Xml framework for the project to compile and work. -- 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: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have
@if user.agent ie6 ie8 {
//...
}
then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.
This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.
On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
I recently noticed that developers are forking c.g.gwt.useragent in order
to be able to add new browser permutations to existing ones. This is
suboptimal and causes code duplication and possibly trying keep it in sync
with the original during updates.
The root cause of this is the determination of user.agent during runtime
is statically defined in this package. I created a patch so that code
snippets to extract user agent can be defined and injected from outside so
that new permutations can be added externally without forking the original
package.
If you hit this issue before, please take a look at https://gwt-review.**
googlesource.com/4500 https://gwt-review.googlesource.com/4500 and see
if would make your life easier.
Not opposed to it in principle, but adding a new user.agent is not an easy
task, and more often than not people actually want to add a new property to
be used in conjunction to user.agent in deferred-binding rules (e.g.
https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
so I'm not sure this is the right move, as it makes it easier to do things
the wrong way.
As a side note, I think we should add a way to alias property values so
we can progressively rename gecko1_8 to gecko and possibly safari to
webkit [1] without breaking anyone. I think this can be faked today
using fallback-value and excluding the fallback value from the possible
values (i.e. extend-property name=user.agent value=gecko
fallback-value=gecko1_8/set-property name=user.agent
value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8
here but thanks to the fallback-value, if-property-is name=user.agent
value=gecko1_8/ should continue to work and match the gecko
permutation) but we cannot set-property the user.agent property in GWT
proper as it would break those who new values and expect the set of
possible values to automatically grow with their new value.
[1] Daniel thinks we should add a chromium permutation –he said blink,
but I believe chromium would be a better name: it's not only about the
rendering engine, but also the JS engine–, I know webkit can be used with
other JS engines than JavaScriptCore but I'm unsure anyone would do it
nowadays, and webkit probably still better matches reality than safari.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
218.248.6165
niloc...@gmail.com
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?
I spent an hour or two last night playing with phloc-css, and it doesn't seem to be quite as flexible as flute in terms of adding custom behavior for unknown @-rules (@def, @sprite, etc), or handling arbitrary (and unknown to both flute and phloc-css) functions like literal() and value(). I played briefly with modifying the jjt file, but realized that any gain made there comes at the cost of re-namespacing and trying to rebase such a change along as phloc-css changes. As a drop-in replacement, I'm not seeing a good strategy here, though I'm open to suggestions. Closure doesn't quite seem a perfect fit either, though perhaps I am missing some details about it (I've only gone through the docs at http://code.google.com/p/closure-stylesheets/ and the wiki), specifically around the @sprite/gwt-image feature in CssResource, but also the other Java-specific pieces like @eval to get outside values into the css and @def to get inside values back out again. Can anyone comment on those aspects of how a GssResource could look? On Tuesday, August 27, 2013 2:19:39 PM UTC-5, Julien Dramaix wrote: Thanks all, I will focus on Closure stylesheets integration and the introduction of a new GssResource Julien On Tue, Aug 27, 2013 at 5:25 PM, Goktug Gokdogan gok...@google.comjavascript: wrote: What we were planning was to add support for GSS, add the missing features and then migrate existing users and deprecate the older eventually. This would decrease the maintenance cost a lot in the long term. We really want to see GSS support for GWT in the long term. On top of additional features, there are other benefits with moving to GSS; Google is committed to maintain GSS and support it in the long term, we can get direct support from the authors as they are close to us. One other major advantage more specific to us is, we can reuse tons of already available GSS resources. For that reason, we would love to see you moving in this route and will definitely help you along the way, and also provide you additional contact points from the team for support. On Tue, Aug 27, 2013 at 3:24 AM, Thomas Broyer t.br...@gmail.comjavascript: wrote: On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote: I'd be interested in helping with either approach. The phloc-css project looks interesting if we are only trying to add support for newer CSS features, while integration with Closure Stylesheets seems geared more toward extending the CssResource featureset. Much of the existing functionality in GWT's CssResource is also in closure in some capacity, though the implementation is likely different enough to cause interesting issues. There are advantages to making it through those differences - mixins for example. Another thought would be to implement both - expand CssResource to support new properties with phloc-css, and create a new ResourcePrototype (StylesheetResource perhaps?) with its own resource generator to put code through closure's wringer. +1 to that (obviously, as I think that's what I was proposing) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Gwt benchmarks without Benchmark
Shortly after 2.5.1, the Benchmark classes were removed from GWT (https://gwt.googlesource.com/gwt/+/39eb6001a037fd8b6580a73a2540e6e9c04e54c2 and https://gwt.googlesource.com/gwt/+/00c7ce43df3a629b7302ab902a07431db7224e2b) - what are folks using for low-level performance testing these days? I'm wrapping up a changeset to emit JS TypedArrays when int[], double[], etc are used in code, and while I can see that some projects clearly improve with this, others seem to take a hit (specifically in rapidly allocating arrays that have a short lifetime). I'd like to record some numbers to paint this picture without rolling my own benchmark/gwtPerf tool, but I'm not quite clear on the current state of this sort of metrics. From the comment that originally deprecated the Benchmark class: This didn't get enough adaption externally or internally. The way it's implemented requires special support from GWTTestCase infrastructure. Also, we are not going have an environment to automate benchmarks written on this any time soon. If there is enough demand later, parts of this code can be resurrected to build a new benchmark system. Thoughts? -Colin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?
I'd be interested in helping with either approach. The phloc-css project looks interesting if we are only trying to add support for newer CSS features, while integration with Closure Stylesheets seems geared more toward extending the CssResource featureset. Much of the existing functionality in GWT's CssResource is also in closure in some capacity, though the implementation is likely different enough to cause interesting issues. There are advantages to making it through those differences - mixins for example. Another thought would be to implement both - expand CssResource to support new properties with phloc-css, and create a new ResourcePrototype (StylesheetResource perhaps?) with its own resource generator to put code through closure's wringer. -Colin On Monday, August 26, 2013 5:38:45 AM UTC-5, Julien Dramaix wrote: Hi all, Just to inform you that I would like to give a try to add support of CSS3 in GWT if nobody is working on. After some research, I found another open source CSS parser in java supporting CSS3 : https://code.google.com/p/phloc-css If we need only a parser it could be a interesting alternative to Closure syle sheet. What do you think ? Julien On Thursday, February 2, 2012 9:38:02 AM UTC+1, Thomas Broyer wrote: On Thu, Feb 2, 2012 at 7:05 AM, Ray Cromwell cromw...@google.com wrote: Sorry to hear that. This is actually on our list of priorities for GWT, so we will have to take this up internally. Just a clarification: I was trying to replace Flute with the parser from Closure Stylesheets, replacing the whole CssResource processing (or creating a GssResource) with one based on Closure Stylesheets should be relatively easy though. For now, my priorities are fixing the remaining RF bugs and hope my half-a-dozen-or-so patches will land in 2.5 (we're helping a company switch to web apps in GWT, and I'd recommend them to use RF over RPC if there wasn't so many pitfalls [1], having the fixes in 2.5 would help make the choice based on the actual features and limitations due to their designs, rather than ditch RF based only on its known bugs [2]). I had very little time these past weeks so I couldn't even try fixing issue 6710 which, to me, is higher priority. So, when I'll have time and have fixed 6710 (the last remaining blocker IMO), I'll see if I can help integrating Closure Stylesheets, but I'm afraid not before. Does that sound good to you? [1] That one in particular caught me when upgrading to a recent trunk last fall, it's not documented and I can't say if it's a bug or simply a limitation due to batching: http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c1 [2] One such example: http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c2 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
I got a tweet from you asking for a donation (or rather a 'partner', which apparently means 'money'), but couldn't frame a useful response in 140 chars, so since this thread is coming back, I thought to do so here instead. What license are you offering these code samples under - if it isn't something open and available, what is the benefit to an advance copy of the jar if I, an author of a library and several open source tools and applications, cannot provide it to my customers or other downstream users? We've found that https://gist.github.com/niloc132/3906501 goes a heck of a long ways toward offering optional debug info - if not enabled, the user gets the normal-size application with zero size or performance hit, and by redirecting to a slightly different url, the full trace info can be pulled out (with the quirks you mention of course*), which typically goes a long ways toward identifying the real issue. * How often have you needed to know which line of Impl.java or DOMImpl.java a stack trace intersects? To make your case more effectively, you might consider using code where it is meaningful to see those lines, something other than the equivelent of java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life JSNI, or an annoying IE6-9 focus() or setAttribute issue? You touch briefly on the risk of '[exposing] your application’s implementation details', but unless I am mistaken, the extra metadata included in the file:line ints should still be enough to take apart an app and map it to discrete files and reconstruct methods, even un-inlining (as you mention) to pull out clearer details. My understanding was that the premise of the sourceMap was to work entirely from the stack to allow the actual source to be obfuscated, and avoid any other metadata from being left in the compiled output. Combine this with the fact that many of those classes are publicly available (GWT itself, etc), and it seems that you could reverse out a significant portion of the app - the secret sauce. Can you comment on using this for public applications and any reverse engineering attempts you've made? On Mon, Aug 19, 2013 at 3:06 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hello folks, I just wanted to remind everyone that the last day to fund this project is this Friday, August 23. I've been using this framework in production in my app now for 2 months, and it works great. Have logged 70,000 perfect stack traces so far! Already fixed 3 major bugs in my GWT-based UI code that I would NEVER found otherwise. Let's get this capability into GWT by the end of the year. Please donate! Thanks, Alex On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote: Dear fellow GWT users, I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production. With my patch, your deployed app will be able to report stack traces like this: com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(** DOMImplMozilla.java:145) com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(** Document.java:1287) com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(** PopupPanel.java:884) com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(** PopupPanel.java:453) com.typeracer.commons.client.**widgets.EnhancedPopup.** EnhancedPopup(EnhancedPopup.**java:32) com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(** PopupWithFocusableTextBox.**java:28) com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand** ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55) com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(** SchedulerImpl.java:50) etc... :-) instead of the current state of affairs that looks like this: lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.htmlhttp://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2422http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2423http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:3190http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2810http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3** B8.cache.html:2289http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 etc... :-( I am asking the community to support me
[gwt-contrib] Re: Nextgen GWT/JS Interop (Public) (google-web-tool...@googlegroups.com)
Nice writeup. Comments/questions (since comments seem disabled in the docs): * @Entry looks great - there has been some discussion in IRC about some way to do this for easier library wrapping code, but every direction we looked at with JSOs ended up with a little more cruft than we really wanted to see. Maybe worth mentioning that $entry doesn't just do exceptions, but also makes scheduleFinally behave as expected. * Constructors - how is one supposed to new up an object that implements a specific interface without making your own implementation (and thus declaring new implementations)? Are we keeping the static-method-only restriction, or can we use new? Similarly, how will these objects pass through the java/js barrier - are they to be a special class of objects in JSNI, allowed to be manipulated in plain JS instead of opaque objects, but still able to be instanceof'd? * Java 8 support/requirement - currently the GWT release jars are compiled to target java 6 (according to common.ant.xml), so that they can be used in a project that supports either 6 *or* 7 (and of course newer). If this new code is used at all internally with java8-only features, does this mean that support will be *dropped* for both 6 and 7 instead of merely *adding* java 8 support? * (JSNI doc) primitives - why support for long, which JS VMs don't actually support, but not float/short/byte? * (JSNI doc) forEach - will there be a function/callback interface that will be autowrapped in $entry and bind to be passed in, or will this simply access a JSO that will be treated as a function? On Tuesday, August 6, 2013 2:24:47 AM UTC-5, Goktug Gokdogan wrote: I've shared an item with you. This is a design doc that describes a proposal for improving interoperability with GWT and javascript. The proposal provides some essential pieces to provide better and easier interoperability with JS while putting more complex scenarios (e.g. Web Components) and testability into account. Please take a look and provide us some feedback. Cheers, - Goktug [image: Document] Nextgen GWT/JS Interop (Public)https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing Google Drive: create, share, and keep all your stuff in one place. [image: Logo for Google Drive] https://drive.google.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.
Colin Alworth has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 8: What is the thinking for the remaining 10%-ish of widgets - all of the cell widgets (except CellPanel), remaining *boxes (DateBox, various number-Box), RichTextArea, missing *LayoutPanels (SplitLayoutPanel, LayoutPanel, HeaderPanel, DeckLayoutPanel), etc? Future patch, or less important? I could see skipping most of the boxes, since the api should be relatively similar since subclasses mostly modify internal behavior, but then you have IsNumberLabel which just makes the generics more explicit (and should almost certainly be extending IsValueLabel to get those other super-interfaces...). Then there are the layout panels which arguably look like HasWidgets.ForIsWidget, but if IsElement gets so specific as to allow direct dom manipulation, it seems reasonable to allow layout manipulation as well. AbstractHasData and subclasses (lots of cell widgets) is a nice abstract class which already has most -- but not all -- methods declared in various interfaces. Unless we're waiting for a future patch to finish the job, I'm not yet understanding the approach in which classes get selected for this treatment and which types/methods get a pass. I don't mean for this to stand in the way of this patch, but to suggest that the strategy is sufficiently unclear that we could probably use a gwt-site doc on this or a body of javadoc that covers how these are intended to be used, and how widget authors/maintainers should behave to make their code usable by downstream users who like these interfaces for testing. -- To view, visit https://gwt-review.googlesource.com/3231 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(1 comment)
File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
Line 172: if (program.isStaticImpl(x.getTarget())
!program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
The extra condition (both here and in GenerateJavaScriptAST) deals with the
fact that MakeCallsStatic registers instance methods as static with
JProgram, while JsoDevirtualizer does not. This seems reasonable at first,
though since JSOs are *always* made static, there might be other
implications. I suggested this in my first comment in this change request,
but John seemed to think that this approach made more sense. That said, I
haven't actually tried making that change, and seeing what else is affected
(i.e. all other callsites of JProgram.isStaticImpl or .getStaticImpl).
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(2 comments)
File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49: static final class ClinitStaticFieldFirst extends
JavaScriptObject {
Correct - the commit message documents this, but I'll stick a comment too.
Line 54: if (FIELD == null) {
Again, commit message touched on it. The bug only manifests in compiled
code, and the compiler will inline this if it is too simple. I was going
for the simplest code I could write that would not be optimized out (at
least in draft mode) without using JSNI. Not that there is an issue with
JSNI here, just that I wanted to keep the issue on track for following Java
semantics. Once the method gets inlined, the bug goes away, since the
outside code is accessing the field, and any static field access requires a
clinit (which the compiler doesn't forget before this patch).
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3361 to look at the new patch set (#2). Change subject: Ensure clinits get called for JSO instance methods. .. Ensure clinits get called for JSO instance methods. In following Java semantics, any static initialization code in a class (collectively a clinit) should be run before any part of that class is used. To achieve this, GWT ensures that this clinit was invoked before any (actually) static method, and as part of any constructor. This way, instance methods are sure to have already run the clinit, so it doesn't need to be run again. However, JSO constructors don't exist, so instance methods are not guaranteed to have had the clinit already run. This is the bug that this patch is trying to fix. Two locations are changed, both with the effect of ensuring that a clinit is emitted for JSOs. First, the MethodInliner must not skip adding a call to the clinit when the jso body is inlined and the method invocation (and ref to the class) is dropped, and second, GenerateJavaScriptAST must likewise write out explicit clinits for any static method or jso instance method. The jso methods for the unit tests include methods that seem slightly convoluted to avoid being inlined - once inlined, the clinit would re-appear (as it shoud, since the static field is being accessed directly). Each situation being tested requires its own type, since the test app would require being restarted to empty out each static field. Note that prior to this fix, only the instance method case failed and returned null - the other situations are added just to ensure that everything else is behaving as expected going forward. Bug: issue 3192 Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb --- M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java M user/test/com/google/gwt/dev/jjs/test/JsoTest.java 3 files changed, 70 insertions(+), 4 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3361 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.
Colin Alworth has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 6: (4 comments) File user/src/com/google/gwt/dom/client/HasStyle.java Line 29: void setStyleName(String styleName); Might be worth adding hasStyleName, as this was recently added to Element - Goktug indicated in that review that a toggleStyleName is on the way as well. https://gwt-review.googlesource.com/#/c/3070/ File user/src/com/google/gwt/dom/client/IsElement.java Line 61: void appendChild(IsElement element); This method seems out of place - it is the closest we get to dom manipulation - no removeChild(IsElement) nor IsElement getParentElement() or any getChild (which may not be). Is there a reason you picked this and removeFromParent, but not other dom methods? Variance issues almost explain it, but then I noticed that you needed to add new methods just to support this in Element itself. And since you already are needing to add new methods in Element to deal with IsElement vs Node, would it make sense then to add new methods for these? File user/src/com/google/gwt/user/client/ui/IsUIObject.java Line 27: IsElement getIsElement(); My concern there would be that we'd no longer have a way to get access to the element as a jso in the code that needs it. If I wanted the element so I could treat it as a InputElement, the JSO.cast() is no longer available to me, only the regular Java cast. Not a huge loss, but it definitely is a breaking change. Simple/ugly way around that might be to rename IsElement.asElement to IsElement.cast, with the JSO.cast generics. Returns null for stubs, and with a real element lets you cast as usual. File user/src/com/google/gwt/user/client/ui/IsWidget2.java Line 28: public interface IsWidget2 extends IsWidget, IsUIObject, EventListener, HasHandlers, (Sorry if I missed this discussion elsewhere, but) What is the philosophical thinking on IsWidget vs IsWidget2? This is for mocking Widget, while IsWidget is for Composite-free composition? If that is the idea, what about another name than IsWidget2, which seems to suggest 'better isWidget' rather than 'mockable iswidget'. -- To view, visit https://gwt-review.googlesource.com/3231 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Colin Alworth has uploaded a new change for review.
https://gwt-review.googlesource.com/3361
Change subject: Ensure clinits get called for JSO instance methods.
..
Ensure clinits get called for JSO instance methods.
In following Java semantics, any static initialization code in a class
(collectively a clinit) should be run before any part of that class is
used. To
achieve this, GWT ensures that this clinit was invoked before any (actually)
static method, and as part of any constructor. This way, instance methods
are
sure to have already run the clinit, so it doesn't need to be run again.
However, JSO constructors don't exist, so instance methods are not
guaranteed to
have had the clinit already run. This is the bug that this patch is trying
to
fix.
Two locations are changed, both with the effect of ensuring that a clinit is
emitted for JSOs. First, the MethodInliner must not skip adding a call to
the
clinit when the jso body is inlined and the method invocation (and ref to
the
class) is dropped, and second, GenerateJavaScriptAST must likewise write out
explicit clinits for any static method or jso instance method.
Bug: issue 3192
Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
index 240f6a0..1c7944a 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
@@ -2189,10 +2189,10 @@
if (!crossClassTargets.contains(x)) {
return null;
}
- if (x.canBePolymorphic() || program.isStaticImpl(x)) {
+ JDeclaredType enclosingType = x.getEnclosingType();
+ if (x.canBePolymorphic() || (program.isStaticImpl(x)
!program.isJavaScriptObject(enclosingType))) {
return null;
}
- JDeclaredType enclosingType = x.getEnclosingType();
if (enclosingType == null || !enclosingType.hasClinit()) {
return null;
}
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
index d2b05ae..6acbb49 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
@@ -169,8 +169,8 @@
// Access from this class to the target class won't trigger a
clinit
return null;
}
- if (program.isStaticImpl(x.getTarget())) {
-// No clinit needed; target is really an instance method.
+ if (program.isStaticImpl(x.getTarget())
!program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
+// No clinit needed; target is really a non-jso instance method.
return null;
}
if (JProgram.isClinit(x.getTarget())) {
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Colin Alworth has posted comments on this change. Change subject: Ensure clinits get called for JSO instance methods. .. Patch Set 1: Afraid not, this is the exact same patch we looked at - only difference was that I pulled the sys.out.println I was using to debug the circumstances for this fix. W.r.t. test cases, would those be best in the form of a test JSO that demonstrates the issue, or something that actually builds a sample ast and verifies that JsInvocations or JMethodCalls are created for the clinit? I have the test sample from the original bug report that could be made into a GwtTestCase, but that seems a little more testing the effect than the bug. That said, I'm not seeing (or perhaps not looking in the right place for) a lot of test cases that make sure the generated JS is sane. One last thought - while moving this from SVN to Git, it occurred to me that this same fix could potentially be achieved in another way: In the same way that MakeCallsStatic ties newly static calls to their original instance version via JProgram.putStaticImpl, it appears that JsoDevirtualizer could do the same. This would make these methods show up as needing a clinit when the `program.isStaticImpl(x.getTarget())` check is made (as in MethodInliner.createClinitCall. From your general gwtc point of view, does that seem to be a reasonable (as well as clearer) fix? -- To view, visit https://gwt-review.googlesource.com/3361 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element
Colin Alworth has posted comments on this change. Change subject: Add hasClassName method in com.google.gwt.dom.client.Element .. Patch Set 6: Code-Review+1 Nope, we can work with it - a wrapper isn't really an option, since we get real benefit from getting static methods that look like instance ones without the mess of static imports or new-ing up instances that wrap the original elt just long enough to run a method on them and gc them (unless the compiler now can unwrap that single final field and method and treat it as if it were static to begin with?). We used to have a great big flyweight thing going on to avoid the extra object creation, but move to extending Element to avoid that little extra cost... My main point was to bring it up as a point to discuss, to make sure that adding a new final method to a non-final class was deliberate. GXT is happy to plan ahead and remove it before 2.6 lands (and thanks for the heads up on toggleClassName), and move to something else in the meantime, we'd just rather not make a habit of that, cutting new specific gxt minor releases to accommodate specific gwt minor releases, and I'm sure we're not alone in that. -- To view, visit https://gwt-review.googlesource.com/3070 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element
Colin Alworth has posted comments on this change. Change subject: Add hasClassName method in com.google.gwt.dom.client.Element .. Patch Set 6: Thanks Goktug - one of the distinct advantages of extending Element is that we can subclass UiObject.getElement and already have access to the methods we want, and on the other side the subclass can invoke Element methods (without the pretend-jso-cast). As I understand it, from your example, GxtElement is superfluous - we'd need to .cast() to GxtElement to even get the .cast() method to get GxtExtensions ;). (wrapping up, as Andrey's code review probably isn't the place...) W.R.T. devirtualization, that doesn't quite go far enough - constructors do not go away, and the this$static is still needed, even though it is only to grab the one field inside it. And while v8 might do the alias analysis and drop the ctor, I'm all by certain that IE6-9 don't (and 10 would be a guess). -- To view, visit https://gwt-review.googlesource.com/3070 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless. To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an input), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton... But this ends up meaning that 'click' events aren't the only thing to worry about - a div won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent). Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by button or input, or perhaps an a?). So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)? On Wed, Jun 5, 2013 at 4:28 PM, Ed post2edb...@gmail.com wrote: The simpler thing than buffering is just to have a StubButton, e.g.: A, how could I forget ;)... I just remember the Stubs* Widgets in your gitHub ;) But is this even needed ? If you use a template mechanism it might not be needed. The template is created during setStyle() and other operations and only used in GWT client mode when the underlying Widget is created... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Slight follow up to both Stephen's comments here and my own prev post - If the interfaces are for existing, standard, built-in GWT widgets, type 2 makes a lot more sense, whereas for type 1, we really seem to need a general, ideal button that can be replaced by any implementation (with possibly any internal rebuilding via appearance/cells/etc). -Colin On Wed, Jun 5, 2013 at 4:36 PM, Stephen Haberman step...@exigencecorp.comwrote: Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. I disagree; I actually prefer Type 1. Although to each their own, of course. However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. UiHandler makes inner classes 2 lines shorter, but IMO it still leads to the same spaghetti code (reactive/imperative, instead of declarative). Tessell's binding DSL makes simple/common operations one line declarations (explicitly via Type 1-exposed widget interfaces, not UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as succinct as: https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43 So I think this argument looses some weight as probably no one really wants to do the type 1 way anymore and only a minority still choose it for new projects. Well, that is unfortunate, as MVP Type 1 with Tessell's view generation and binding DSL is quite pleasant. But, again, to each their own. :-) No need for GWTMockUtilities.disarm() or gwtmockito then. Exactly. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element
Colin Alworth has posted comments on this change. Change subject: Add hasClassName method in com.google.gwt.dom.client.Element .. Patch Set 3: Code-Review-1 As an idea, looks good, but remember that JSOs are a particularly bad place to add new arbitrary methods, especially mid-release (i.e. consider 3.0). Any downstream code that extends Element and has a method with the same signature is going to break. As an example (admittedly, one that I am biased toward), GXT has a Element subclass class that supports this very same method signature, hasClassName(String). Adding final methods to non-final classes in general must be done carefully - since in a JSO either all methods must be final or the type itself must be final, all new methods should be carefully scrutinized. My vote would be that this would be implemented in a different way to not require new methods, at least for 2.x - breaking changes with downstream code isn't generally expected in minor releases (though that hasn't stopped us in the past, see JClassType about 2.2.0). The 3.0 release might be a better target for the patch as-is. -- To view, visit https://gwt-review.googlesource.com/3070 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...
Colin Alworth has posted comments on this change. Change subject: Use JSON.parse() instead of eval() to deserialize rpc callback payload .. Patch Set 1: (1 comment) The ServerSerializationStreamWriter will also need modifications, two that I can think of: * writeLong currently is using instead of ', which isn't valid in JSON. This should be failing in the unit tests, as long as testing something that uses parse instead of eval. * very large payloads will now break when the array concatenating code kicks in, writing ].concat([ to join arrays that are otherwise too big for ie6/7 (and 8?). This isn't valid JSON, so this will break when the object graph reaches a certain size. Can you make sure to run the unit tests remotely in each IE version to verify that you changes will behave? I believe there is a test for each direction of each primitive, but not a test for very large data sets. File user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStreamWriter.java Line 97: append(0); Infinity does actually work round trip in my quick testing in this way, as 1e1000 or the like is a) legal json and b) outside the range of double, so will end up as +Infinity on the JS side after parsing, or when wrapped up in Double.parseDouble. However, 0 being used as NaN won't fly, you're right. One idea is to emit null, then read out the null as a special case - in my testing this behaved well in all browsers. Sending the strings +Infinity, NaN could also work, but then you need parse those as strings, not as numbers after reading it as json, i think in my first try at this I decided that was more trouble than it was worth. No need to use = or = for infinity checks, == should be sufficient. writeFloat will also need similar treatment. -- To view, visit https://gwt-review.googlesource.com/2900 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: IE10 support in Gwt
In most cases that is true, but CssResource is an interesting exception. The fallback rules work by looking to see if there is no implementation for a particular value, and if not, looking to see if there *is* an implementation for some other value. In the case of ClientBundle and CssResource, they are generated at compile time - when you refer to @if user.agent ie9, that will be compiled *only* into the ie9 build, and not into any ie10 build, which will only contain non-qualified code or statements that actually evaluate to true for ie10. But yes, otherwise it should behave as you've described. On Monday, April 22, 2013 5:01:56 AM UTC-5, Honza Rames wrote: It does but out of curiosity, if I add IE10 permutation/browser detection to UserAgent.gwt.xml to which value should I set the property-fallback? I mean is property fallback-recursive (I would assume it is) so setting it to IE9 should work? In case IE9 rule isn't specified it will recursively fallback to IE8 (and generate a compiler warning) right? On Wednesday, April 17, 2013 12:40:04 AM UTC+2, Thomas Broyer wrote: On Tuesday, April 16, 2013 2:07:34 PM UTC+2, Mariusz Magdziarz wrote: When you add support for IE10?? AFAIK, IE10 works OK with the ie9 permutation. Vaadin has started working on bringing MSPointerEvents to support touch-enabled (and touch-only) devices. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] widget interfaces
On Thu, Mar 21, 2013 at 9:24 PM, Stephen Haberman step...@exigencecorp.comwrote: Also we can use this as an opportunity to provide a compatibility layer across different vendors and/or different widget systems. I suppose, technically yes. That is more complex than what I really had in mind...but if gets me widget interfaces, I suppose I'm interested. In general I'm skeptical about vendor agnostic widget APIs, because given how nit-picky perfect UIs have to be, it doesn't seem realistic to be able to switch implementations and still have things look right (other than some trivial theming). Agreement on this point - within GXT we annoy developers by not implementing HasClickHandlers on our buttons, but instead using our own HasSelectHandlers (distinct from HasSelectionHandlers). This frees us to not require the 'click' event to activate a button - the user can tab into a button and hit the space bar, even if the dom element doesn't magically turn key events into clicks. Likewise some menu items (i.e. those with a sub menu) activate on hover, while others on click. We've made a point of distinguishing between the dom events and the logical events - effort to standardize these interfaces will need to be careful to cover these details. In upcoming weeks, we will start talking more about improving UI+widget development in GWT. It is good to wait until that gets more concrete before introducing/changing any APIs. No problem. Sounds interesting! Also, I'm really glad to hear you'll be keeping us non-Googlers in the loop. Perhaps it is naive, but with the re-open sourcing of GWT, I'd love to see more of Google's internal conversations about GWT happen in a public forum, like gwt-contrib. Totally understood that you can't discuss internal business details on a public forum, but it seems like a lot of open source projects have technical, cross-company discussions on their open mailing lists. +1 -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? On Mar 16, 2013 1:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Thanks John for clearing this up. This was exactly what I had in mind. I will close the issue AsDesigned, maybe we should document this is little better. -Daniel Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
If you call a method or access a field from pure JS, you aren't going to
get the JSO implementation -
com.google.gwt.dom.client.Element.removeClassName(String) doesn't exist in
the underlying browser, so we build it in Java, and talk to methods/fields
which *do* exist in the browser. In other cases we dispatch to static
methods that exist elsewhere in GWT. You can't call it from pure JS, so how
it works or what it needs shouldn't be considered when looking at how JSO
should behave and what code should be emitted.
There are many static fields which exist in existing JSOs already, but most
(all?) are final, and are Strings or other primitives, so are already
constants, not just fields. In the linked bug, an array is being kept, and
it isn't initialized in time. I've only found one case of a static field in
a JSO, and the docs suggest that it is optimized for dev mode.
Hypothetically, if Document were subclassed (it isn't final) and get() were
invoked by an instance method (consider referring to another document from
within an iframe), this issue could be tickled if it weren't for that
'optimization':
/**
* We cache Document.nativeGet() in DevMode, because crossing the JSNI
* boundary thousands of times just to read a constant value is slow.
*/
private static Document doc;
/**
* Gets the default document. This is the document in which the module is
* running.
*
* @return the default document
*/
public static Document get() {
if (GWT.isScript()) {
return nativeGet();
}
// No need to be MT-safe. Single-threaded JS code.
if (doc == null) {
doc = nativeGet();
}
return doc;
}
I recognize that the primary intent of JavaScriptObject is to offer a Java
API to a JavaScript object, but there are plenty of cases where that JSOs
are used to achieve other points, or contain logic beyond what might
normally be necessary. Ray Cromwell wrote a post a few years ago that
encouraged using JSOs to 'cheat' the Java type system a bit -
http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html
- these examples don't make use of fields, but it seems a logical next step
to add a little logic to some of these psuedo-categories.
To look at my own use case, GXT extends Element as XElement to allow Java
method calls to cache some values as XElement is used. We've worked around
this by moving those to a static inner non-JSO type - they remain private,
static, and final, and behave as expected with this workaround.
So, with all of this in mind, a change to make this 'as designed' will
warn/error on any static field that is not a) final and b)
String/primitive, and on any static block? Or, can we consider the utility
of the JSO class to be something that is actually meant to be used only
from Java, so we don't care what happens to the underlying JavaScript
object, and how that continues to behave as JS normally would?
On Saturday, March 16, 2013 4:43:13 PM UTC-5, John A. Tamplin wrote:
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
The problem with this answer is that the failure is silent and surprising
for Java developers, and that the optimizations can make it even more so.
If I recall correctly, calling a static method in the same type from an
instance method is not enough to get the static initializer called - an
optimization prunes the clinit.
I have a patch that restores clinits from instance methods, but I'm out
of reach of it at the moment. I haven't made a code review yet in the
interest of adding tests for this case.
I don't see how you can add clinits on a JSO -- the point is it is a plain
JS object under the hood (ignoring all the magic to make it work in
DevMode). If you call a method or access a field from pure JS, how can it
know to call the clinit?
If we do decide that cl units should be pruned, we should stop cutting
them from other newly 'static' methods - at least in that case bit must be
a bug. If not that, then emit a warning?
I'm fine with making it an error.
--
John A. Tamplin
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Code Coverage
I haven't been using maven to run my tests in the past (because I don't want them package into the war and increasing the size of the war) now I'm struggling to get maven to build and run my tests at all. They're in a separate folder outside of src. I guess I don't understand this part - if maven doesn't know about the test sources, it makes a certain amount of sense that mvn emma:emma does nothing. Additionally, if those sources are reported to maven as test sources, they should never make it to the compiled war. The standard maven project setup for a war project looks a little like this, give or take (with added bits for GWT), including a single test class: project/ pom.xml src/ main/ webapp/ index.html WEB-INF/... java/ com/company/project/ Project.gwt.xml server/... client/... shared/... test/ java/ com/company/project/client/MyTest.java The important details here are that the test sources are not in the src/main/java tree at all, so maven should never be building them into the war file. Its possible your IDE (esp if that IDE is eclipse...) is cheating a bit, but no maven process will make that mistake. With this standard setup, the emma:emma goal seems to behave on maven 2.2 or so. Can you clarify on how you are setting your project up, and perhaps make/share a sample project? I'll see if I can find/share a sample on github that demonstrates working emma coverage, given these basic setup details. On Wed, Mar 13, 2013 at 10:57 AM, darkling darkling...@aol.com wrote: Do you mean you're using the surefire test goal or the gwt:test goal? I've spent a few days trying to get either working without much luck. I haven't been using maven to run my tests in the past (because I don't want them package into the war and increasing the size of the war) now I'm struggling to get maven to build and run my tests at all. They're in a separate folder outside of src. Which maven goal approach did you take to running emma? Thanks On Friday, March 8, 2013 6:13:11 PM UTC-5, Colin Alworth wrote: We've been using the Maven2 emma:emma goal, with no modifications at all - seems to behave correctly with htmlunit in dev mode, both for traditional junit tests and GWTTestCases. No changes to the pom, just executing emma:emma with maven 2.2.1 on our project. On Thursday, March 7, 2013 11:01:37 AM UTC-6, darkling wrote: Does anyone have any recent experience working with a code coverage tool and GWT? I heard that emma worked so I downloaded the eclipse emma plugin and gave it a whirl. The problem is it only seems to tell me that no line of mine was ever touched. I tried running it on my nonGWT code and it seems to work fine. But GWT gives me no answers. I read a post saying that the emma approach doesn't work with the latest version of GWT (I am using 2.4) can anyone confirm or deny this? Thanks -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Code Coverage
We've been using the Maven2 emma:emma goal, with no modifications at all - seems to behave correctly with htmlunit in dev mode, both for traditional junit tests and GWTTestCases. No changes to the pom, just executing emma:emma with maven 2.2.1 on our project. On Thursday, March 7, 2013 11:01:37 AM UTC-6, darkling wrote: Does anyone have any recent experience working with a code coverage tool and GWT? I heard that emma worked so I downloaded the eclipse emma plugin and gave it a whirl. The problem is it only seems to tell me that no line of mine was ever touched. I tried running it on my nonGWT code and it seems to work fine. But GWT gives me no answers. I read a post saying that the emma approach doesn't work with the latest version of GWT (I am using 2.4) can anyone confirm or deny this? Thanks -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
