Re: Deploying symbolMaps in a production build

Symbol maps are distinct from source maps, the serve different purposes. Sourcemaps, when deployed with your actual source, allow the browser to ask the server for your Java source, so you can see if when you debug - this may not be something most production applications want their customers to

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

where code came from in an external project, make sure everyone is on board with moving to gwtproject. On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote: > > > > On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote: >> >> Thanks guy

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

Thanks guys - I guess I'm confused as to why Daniel and Thomas have their projects so far in their own repos, and not in github.com/gwtproject - I was following that example. If you guys are ready to move them now and ship them (0.9 or 1.0-beta-n, either works for me) to central, then I have no

[gwt-contrib] Deploying to org.gwtproject.* groupId

I'm about to put out a blog post with a bunch of details on how one might port gwt-user.jar modules out (thanks to the hard work of those who have started this effort already, especially Dan Kurka and Thomas Broyer), and once those are ready to be consumed, we'll certainly want the various

Re: [gwt-contrib] GWT csrf protection EXPERIMENTAL methods

To answer the original question, no - no changes are planned in the Xsrf variants of generator-based RPC. We should remove those comments. I am aware of no reason to not use the Xsrf variants in production code. Looking forward, beyond gwt-user.jar, I have the core of RPC working correctly in

[gwt-contrib] GWT 2.8.2 release

Today we released the next version of GWT, version 2.8.2. A few quick highlights from this new release: - GWT can now run on Java 9 (though Java 9 features are not yet supported, coming soon!) - Chrome 61 change in getAbsoluteTop/Left has been fixed - Errors on the page reported

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Wed, Oct 11, 2017, at 02:01 PM, 'Goktug Gokdogan' via GWT Contributors wrote:> > PS: pls avoid the urge to discuss technical stuff in steering commitee > and try to keep it in the contributor list ;) If we could get the monthly (weekly?) contrib calls going again so we have someone to

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

Patch is accepted and merged into upstream HtmlUnit, see https://sourceforge.net/p/htmlunit/bugs/1924/ for more detail. Daniel, when you can take a look at Thomas's question, we can get this change made to open source GWT as you requested. -- You received this message because you are subscribed

Re: application compiles in 2.8 but does not run

I can report that at least as of 2.8.1, you get an exception if you specify an that doesn't implement EntryPoint, but still has the correct public void onModuleLoad() signature. I didn't investigate too deeply, but the compiled output was something like null.onModuleLoad(), which indicated to

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

Like we do for com.google.gwt.junit.RunStyleHtmlUnit.HostedJavaScriptEngine so we can hook in the "plugin". Looks like that idea might be a winner! Just make sure to swap it in both cases, don't want to kill tests in old dev mode. -- You received this message because you are subscribed to the

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

Exactly - I wasn't planning on adding the javaToJs(), but was going to unwrap the exception before calling onerror (or have ScriptException implement Scriptable). Have a short test that demonstrates the issue without gwt (but wow they have a lot of GWT in their source tree), and am was waiting

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

It was not my intention to get this into 2.8.2, but to wait for 2.9. If we think it is important enough, I can look into it, but I figure we have to draw the line somewhere... -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

Okay, I'm about 80% sure that I understand and can remedy the problem within HtmlUnit itself. Will update once I finish syncing the apparently canonical SVN repo to git, so I can go over the history more carefully and ensure that this break isn't deliberate. A question for my fellow GWT

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

ard Output --- Logging initialized @1669ms jetty-9.2.z-SNAPSHOT Started c.g.g.j.@358ee631{/,file:/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www/,AVAILABLE}{/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www} Started ServerConnector@2448bc21{HTTP/1.1}{0.0.0.0:6464

Re: [gwt-contrib] Last call for GWT 2.8.2 patches, and testers needed!

Juan, you just signed up, thanks to you and Boris for being so consistently helpful with GWT. Anyone else can feel free to either reply to the list, or email me personally. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

Seems like a good reason to defer to GWT 2.9. On Mon, Oct 2, 2017, at 02:48 AM, Thomas Broyer wrote: > Note that this means GWT will effectively require JDK 8 for > development (gwt-servlet could possibly still work with 1.7, though at > that point I'd push for 1.8 too)> >

[gwt-contrib] NodeList and JsArrayList.asArray

Using GWT 2.8.1, I'm trying to iterate through items found via a query selector: Arrays.asList(document.querySelectorAll("button.with-some-class").asArray ()).forEach( item -> doSomething(item) ); Unfortunately, this seems to always fail - querySelectorAll returns a NodeList, and while

Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

, <T, V[]>, <T[], V>, <T[], V[]>, so I don't think this is a serious suggestion). Otherwise your email seems to suggest that we need a type in jsinterop.base for all JS arrays instead of our current situation of pretending that java arrays and js arrays are compatible. --

Re: [gwt-contrib] Fwd: Usage of file handles/file streams in GWT source code

be able to throw in setHeader). Or is there something concerning in handleRequest that you see which can surprisingly error out before page.send(...) can be reached? -- Colin Alworth co...@colinalworth.com On Mon, Jun 12, 2017, at 04:29 AM, Thomas Broyer wrote: > Moving discussion to

[gwt-contrib] Re: Java 9

Are there specific Java9 JRE classes that we should focus on to get into GWT? Would making GWT support Java9 sources and running in a Java9 env cause backward incompatible changes that prevent GWT from running in Java8? On Wednesday, June 7, 2017 at 2:56:46 PM UTC-5, James Nelson wrote: > > As

Re: GWT 2.8.1 release

; > I thought google didn't want to release them before they were "ready". So > either they changed their mind, or they feel it is ready or I don't > remember correctly :-) > > Vassilis > > On Wed, Jun 7, 2017 at 7:17 PM, Colin Alworth <nilo...@gmail.com >

Re: GWT 2.8.1 release

The groupId has changed - using the mvnrepository site, try https://mvnrepository.com/artifact/com.google.elemental2 to see all of the jars now available. On Wednesday, June 7, 2017 at 11:14:33 AM UTC-5, Bruno Salmon wrote: > > > >> Additionally, this supports the recent beta release of

Re: [gwt-contrib] Re: Upgraded from GWT 2.6 to 2.8 - now Chrome Extension API doesn't work...

If it is the linker, going back to your 2.6 code and changing to the current xsiframe linker might show the bug - if so, you know it is related to the default linker change. If not, debugging your JSNI to see what the value of chrome is before and after the GWT version change will be helpful,

[gwt-contrib] Re: Upgraded from GWT 2.6 to 2.8 - now Chrome Extension API doesn't work...

What had been the care previously? Were you calling the chrome methods in some way other than through JSNI? Java methods can't call raw JavaScript without JSNI (or JsInterop, which didn't exist in GWT 2.6). Otherwise I'm not sure what you changed it _from_ to get to the psuedocode in your

[gwt-contrib] GWT 2.8.1 release

I'm very pleased to announce the release of GWT 2.8.1. This contains many bugfixes and a few enhancements to JsInterop. Highlights from release notes: - Elemental1's JSON parser now correctly throws an exception when a string, object, or array is not correctly ended. -

GWT 2.8.1 release

I'm very pleased to announce the release of GWT 2.8.1. This contains many bugfixes and a few enhancements to JsInterop. Highlights from release notes: - Elemental1's JSON parser now correctly throws an exception when a string, object, or array is not correctly ended. -

[gwt-contrib] Re: Time to remove GWT-RPC from WebAppCreator sample app?

Dissenting opinion, mostly for the sake of discussion (though I'll admit to being an RPC fanboy too): This came up in discussion in ##gwt today, from the other perspective - the stockwatcher app uses JsonpRequestBuilder, which is incompatible with JsType without some seriously fugly casts (as

Re: [gwt-contrib] auto generation of jsinterop from .d.ts

Is the current plan to open source the experimental part as well? I suspect there are people on this list who would be very interested in helping to continue that effort. On Tuesday, April 18, 2017 at 6:52:57 PM UTC-5, Julien Dramaix wrote: > > We are working internally on a jsinterop generator

[gwt-contrib] GWT 2.8.1 release testers required!

are available to spend a little time testing over the next few days, and I'll get the ball rolling. 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, sen

[gwt-contrib] Re: 2.8.x release

Yes, there is a plan to do a release - this is in part my fault for failing to communicate this correctly (by way of steering committee meeting notes). We are waiting on a few patches before we can start the testing process and get the release under way. On Friday, March 17, 2017 at 9:13:09

Re: float[] is super slow

There are other problems too, like supporting object instanceof float[] (or even instanceof Object), not that you likely do a lot of things like that. I had a patch once upon a time that would let you optionally use typed arrays _or_ js lists as primitive arrays (except longs of course), but it

[gwt-contrib] Re: Size of output is little large

Without actually compiling the code (see my final paragraph...), you might not even need the safari permutation, but might get by with no UserAgent wiring at all. You could experiment with your inherits statements, and see if you can remove User, and only depend on com.google.gwt.core.Core from

[gwt-contrib] dead classes and docs

As previously mentioned, I'm walking over a lot of old GWT and playing with some ideas around structure changes. Along the way, I've found some apparently dead classes, and some very rotten docs. For example, at the root of each zip release including 2.8.0, we have about.html, which proudly

Re: Problem with GWT 2.8

At least it is inconsistent with what the JVM would do, and appears to be different from what was seen in earlier versions of GWT. Can you file this at github.com/gwtproject/gwt/issues? On Sunday, November 20, 2016 at 5:35:44 PM UTC-6, Kevin Langille wrote: > > Thanks for the reply. > >

[gwt-contrib] Utils

I've spent a little time over the last week trying again to tease apart GWT into smaller modules and working out dependencies between them. This is in part to see about a not-ant build system, and in part to see why a minimal GWT app is surprisingly big. The target here isn't the user lib, but

Re: [gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

I agree entirely, just trying to see this as a potential contributor with its associated steep learning curve, and address the question of "Should we stop adding new features?". we're rather in a situation of "I'd like to add this new feature to GWT; > and this is something I could do in my

[gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and without 3.0 actually in sight, 2.x is going to need to see active development. Encouraging a third generation of url tools is not a bad thing, but only switching over half-way leaves something to be desired. I'll play

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

Another issue at may warrant attention - https://github.com/gwtproject/gwt/issues/9424. This was brought up some time ago, but wasn't reduced to be reproducible until now (which is funny, given how minimal the test case is). On Fri, Sep 9, 2016 at 9:30 AM 'Daniel Kurka' via GWT Contributors <

[gwt-contrib] Missing JsInterop 1.0.0-SNAPSHOT

Looks like somehow the JsInterop jars are missing from the google-snapshots repo now, making it difficult to use the latest nightlies. http://build.gwtproject.org/job/gwt/615/console shows creating, signing, and deploying: Signing and Deploying ./poms/jsinterop/pom.xml to

Re: [gwt-contrib] Problem with JsInterop

Part of the problem would come from figuring out how to call from JS back into Java - if you called resolve(null), was null a T or was null a Promise? And from JS, how could you typecheck to figure out whether to call the resolve_1(value) or resolve_2(promise)? Its also possible in JS to call

Re: [gwt-contrib] Re: Last call for GWT 2.8.0 RC2

Kay, can you offer a reproducible example of this, and confirm that you have no older copy of GWT (like gwt-user/gwt-dev from 2.8.0-beta1) on your classpath? To test this, I just built some quick autobeans in a simple project (so that I didn't need a full server to back it): public

Re: [gwt-contrib] Re: Bean Validation

What maven repo has the SNAPSHOT in it? Is https://github.com/ManfredTremmel/gwt-bean-validators the source for this? Great work, looking forward to putting this to use, and porting it to annotation processors for long-term GWT support! I'm working with Frank Hossfeld on porting Editors to APT

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

te: > We cannot impose @JsFunction restrictions on standard library > @FunctionInterfaces. You can see some of the limitations in the Javadoc. > > @Colin: I didn't understand your solution. Feel free to propose something > more concrete and we can discuss over that. > > On Wed, M

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

Unfortunately, you can't add the annotation to an interface with more than one method, even if those methods are default methods, at least as it is currently implemented. I can't remember the exact specifics around why this is the case, but believe it has to do with handling functions passed from

Re: [gwt-contrib] Re: Generator and Linker maintenance and changes

Thanks everyone. Since we don't really have much of a consensus on this, perhaps we can take some middle ground here? I certainly agree that we want people to move away from generators in general, though without finished solutions for some of the tricks generators can do, this will be tricky.

[gwt-contrib] Generator and Linker maintenance and changes

seen as a powerful tool for Java web developers! 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-contributor

Re: [gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

.com/niloc132/5cf8162ccc3503215f12d151f4c03168 Patch is done, will have it up soon after a bit more poking. On Friday, April 29, 2016 at 4:38:15 AM UTC-5, Thomas Broyer wrote: > > > > On Thursday, April 28, 2016 at 11:47:48 PM UTC+2, Colin Alworth wrote: >> >> I didn't know how hard and

Re: [gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

Should, and does if you have no enforcer. We needed the enforcer due to arguing between far downstream dependencies from assorted other projects that kept resulting in fun conflicts (in cases where there was no guaranteed backward compat). I'll make up a patch, thanks, I didn't know how hard and

[gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

It looks like a recent change is causing what is technically a version conflict in GWT when used from maven. A project I work on uses the maven-enforcer-plugin to avoid conflicts, and in a rebuild this morning we ran into this error. [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

t; > On Wed, 27 Apr 2016 at 15:50, Colin Alworth <niloc...@gmail.com> wrote: > >> Thanks. Can you confirm that org.w3c.dom is your own code, and not part >> of GWT, so it was just out of date? I don't see a jar with that name on >> your classpath, and neither of the two Ent

[gwt-contrib] Re: Elemental 2 and J2CL timeline

I can't speak for J2CL's timelines, as it is an internal project at this time. However, it has been stated that it will support GWT's JRE emulation and JsInterop out of the box, and the expectation is that it will simply be a transpiler and won't support generators (suggested that projects move

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

, April 27, 2016 at 8:46:13 AM UTC-5, stuckagain wrote: > > Colin, > > The stacktrace was is my initial post. > > Anyway: I managed to find the root cause and solution. > > The super source java file is using JsInterop to map org.w3c.dom API's. > It had annotations like th

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

Can you share the stack trace, the file it is attempting to read, and your classpath? It does sound like it might be a bug, but without the ability to reproduce, it is difficult to say more. One case where it might not be a bug despite its behavior: where it is reusing gwt-unitCache or the like

Re: [gwt-contrib] Lambda overhead

Meta: it would make my year if we could get one of these compiler discussions happening once a week on a public forum like this, both for better basic understanding about why some of these concepts are not trivial, and for better visibility into what else is going on in the process of continuing

[gwt-contrib] Re: dev tests failing locally?

Confirmed, isPublic is true in all three cases, as expected, without the old code in place. On Tuesday, April 19, 2016 at 9:20:10 AM UTC-5, Colin Alworth wrote: > > There is no MOD_DEFAULT, at least not yet. I initially attempted to add > one and tried to copy the same

[gwt-contrib] Re: dev tests failing locally?

ril 19, 2016 at 9:10:05 AM UTC-5, Thomas Broyer wrote: > > > > On Tuesday, April 19, 2016 at 2:37:03 PM UTC+2, Colin Alworth wrote: >> >> As an aside, the fix for the original bug seems to be very easy - the >> code that is building the JMethod instances seems to be

[gwt-contrib] Re: dev tests failing locally?

As an aside, the fix for the original bug seems to be very easy - the code that is building the JMethod instances seems to be overzealous about what modifiers must be applied. Aside from the constant failures, all compiler tests pass with this change: diff --git

[gwt-contrib] dev tests failing locally?

I'm looking into fixing the javac.typemodel.JMethod creation to make it support static and default methods in Java8 interfaces so that generators (at least autobeans and requestfactory) can easily support categories without external classes (see https://github.com/gwtproject/gwt/issues/9289,

Re: Differences between permutations

If you only set one possible permutation, your .nocache.js won't attempt to detect which browser is running, and will always use that one. Only if there is more than one possible value will it attempt to find out which is appropriate. On Saturday, March 26, 2016 at 5:38:53 PM UTC-5, Kirill

Re: [gwt-contrib] Re: New Error caused by recent Chrome Update: RangeError: Maximum call stack size exceeded

The only issue I know of that causes this is https://github.com/gwtproject/gwt/issues/8233 (and also apparently https://github.com/gwtproject/gwt/issues/8229), which is fixed in GWT 2.7. This issue was caused by invoking a method with many arguments, rather than wrapping those arguments in a list

Re: [gwt-contrib] Trying to use JsInterop to work with React

Yikes, that's rather opinionated. I don't personally work with React, but I guess I'm surprised that it can't handle actual inheritance (or even defining a prototype and attaching it to a constructor). Based on what you have there and the details described at

[gwt-contrib] AutoBean wrapping on List method return types

In preparation for submitting a patch with Java8 Streams to GWT, I've been using streams in more situations, and have found a case with AutoBeans where they don't behave correctly. Specifically, AutoBeanFactoryGenerator builds a "shim" type for each object that it will interact with, starting

[gwt-contrib] Re: Compiler failing with java 7

has >> been released so that GWT 2.8 stays Java7 compatible. I don't know >> about the Guava issue that requires GWT 2.8 to already have Java8 APIs >> available. I thought Guava will just release Guava 20 when 2.8 is >> released because Gauva 19 did use some private APIs of GWT t

Re: [gwt-contrib] Re: CSS Resources are not set in Panels in an iframe

As long as both $wnd and $doc exist in the frame where you plan on creating/rendering widgets, it shouldn't matter how you create or find the iframe. This should only mean that your frame must be created when that line of bootstrap code executes, either because you created it there, or because you

Re: [gwt-contrib] Remove unused code of external JavaScript file?

blob/master/modules/javascript/src/main/webapp/javascript/atmosphere.js > > Could you please give an example of how you would do it in this case? > > > Am Donnerstag, 31. Dezember 2015 01:17:44 UTC+1 schrieb Colin Alworth: > >> It depends on how you are including the JavaScript source. >> >> If it is a

Re: [gwt-contrib] Remove unused code of external JavaScript file?

It depends on how you are including the JavaScript source. If it is a

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

If I could be permitted to slight restate what Julien just said: We will make a note of it, as we have done in the past, such as when the default moved from java6 to java7: http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1. That being said, we of course welcome any community

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

Sorry, I hadn't understood that your primary interest was in release dates, but though it was more for compatibility with upstream or related tools on release. That said, I think that the list of downloads at https://code.google.com/p/google-web-toolkit/downloads/list may prove useful for

Re: [gwt-contrib] I think the 2.7.0 GWT release was compiled on Daniel Kurka's machine !

This was also specific to .gwtar files, which will no longer be shipped with the release. This also means the total size will drop, from around 30 mb to 16 mb. On Mon, Nov 23, 2015 at 2:11 AM Arnaud TOURNIER wrote: > I confirm this is absolutely not a bug, and does not have

Re: [gwt-contrib] GWT 2.8 RC1

Paul, do keep in mind that the latest in git (and the 2.8.0-SNAPSHOT in maven) is fairly stable. Some projects (for example, everything that Google makes) live off of trunk, and many projects upgrade to a snapshot, test that things are sane, and then 'pin' that build internally to keep running

Re: [gwt-contrib] Bug in 2.8.0-Snapshot

As this isn't a NPE (or a type error, which I think is the JS equivalent), the we're missing a step here. You are seeing an UmbrellaException thrown, which means not that the handlermanager or event wiring broke, but that your own handler threw the exception (i.e. the 'TypeError' described in the

Re: [gwt-contrib] Java to WebAssembly Compiler

Without GC, I think its going to be a bit of a non-starter - the same issues that apply to compiling to asm.js apply here too. I've heard a few ideas floated around to just compile specific methods to asm.js, and those same ideas seem that they could work, but the really hard part is isolating

Re: GWT2.8 JsInterop Java-JS

) reference to a Js.js(...) class that might do what I want. Apparently, it doesn't exist. Oops. At the risk of sounding snarky, GWT is a poorly run project, consistently overpromising and underdelivering. On Wednesday, May 20, 2015 at 12:18:41 AM UTC+10, Colin Alworth wrote: JSON.stringify

Re: GWT2.8 JsInterop Java-JS

() { MyData data = new MyData(Colin, 123); Window.alert(stringify(data)); } public static native String stringify(Object obj) /*-{ return $wnd.JSON.stringify(obj); }-*/; @JsType public static class MyData { public String name; public int age; public MyData(String

Re: GWT2.8 JsInterop Java-JS

The '_1_g$' indicates you are in super dev mode - does it work correctly when fully compiled to JS (draft or no)? I saw a problem in this area a few weeks ago. Also, can you post the full definition for MyObject? I agree with Alberto though, your printObj doesn't make any sense as is - it is

Re: [gwt-contrib] Open reviews

There is a document outlining which maintainers exist for various parts of GWT, designed to suggest an initial reviewer or reviewers for a new patch/bugfix/feature. https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit This list is in the top (stickied) post in

Re: [gwt-contrib] Jsni on String methods in GWT 2.7

Getting offtopic, but there is absolutely no requirement that JSO methods are public. See dom.client.Element for several examples of private methods. On Mon, Mar 30, 2015 at 10:27 PM James Nelson ja...@wetheinter.net wrote: Ok, great. Thanks for the heads up. I was pretty sure that Strings

Re: [gwt-contrib] Java8 emulation

The trick seems to be that it is not going to be possible to add Java8 emul code without actually using Java8 - while lambdas can be avoided, defender methods cannot. If you need to provide a new interface like Consumer, the supersource *must* have the `default` method(s), or it won't actually be

Re: [gwt-contrib] Re: What constitutes an acceptable emulated String.format implementation?

I'd be strongly in favor of a StringFormat class - this could be library-ized easily, letting someone opt in to even having it in their project, or call it. Since we're changing the API (though I assume keeping the 'format string' language), you could take other steps to ensure small complied

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

Its not that 3k is huge, its that it would be (to a developer, accustomed to GWT's policies) massively larger than normally expected for built-in methods. Just ran SOYC on a project (OBF but not closure), and the largest java.lang.String method is 466 bytes, greater than twice the size of the next

Re: [gwt-contrib] Possible compiler bug in 2.7 ignoring a set-property

I don't recall if inherited modules are loaded more than once - in other words, if one of the higher up modules (like BaseGWT) already inherited BaseBrowsers, then a later module added ie10 via extend-property, it might not be possible to re-inherit BaseBrowsers and have it re-set user.agent down

Re: [gwt-contrib] support for JSR 310 / java.time created

Are you planning on being at either GWT.create event? I know several people (including myself) who will be there and would be happy to help. Otherwise, there are several contributors in ##gwt on irc.freenode.net who would be able to help with this process. On Mon Jan 19 2015 at 4:44:01 AM

Re: GWT compile fails with default Maven directory structure

It sounds like you have non-gwt-capable classes in packages meant for GWT - is that deliberate? For example, test classes to make sure the various server components in your project work, but they are in your .client or .shared package? If they are not, then GWT will totally ignore them, as no

Re: [gwt-contrib] Re: Upgrade 2.7 beta1 to rc1 - browser refresh and change detection not working

It is also possible that there is a stale copy of .java resources on your classpath, such as in target/classes/ for a maven project - we've seen that get in the way as well. Make sure that either target/classes/ isn't on your classpath, or that it doesn't have another (stale) copy of whatever you

Re: PSA: starting unbundling dependencies from gwt-dev published to Maven Central, could break your build

/ Contents/Home/bin/java -Xmx512m -classpath /Users/colin/Documents/idea/gwt- rpq/rpq-samples/target/classes:/Users/colin/Documents/idea/gwt-rpq/rpq- samples/src/main/java:/Users/colin/.m2/repository/com/google/gwt/gwt-user/ 2.7.0-SNAPSHOT/gwt-user-2.7.0-SNAPSHOT.jar:/Users/colin/.m2/repository/javax

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

, Thomas Broyer t.bro...@gmail.com wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required resource tags causing warnings, etc). On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com javascript: wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass

Re: [gwt-contrib] Removal of IE6/7 specific code from the code base

I've just submitted a shallow removal of IE6 specific code in https://gwt-review.googlesource.com/#/c/9513/ - this patch starts with all .gwt.xml files that mention the user.agent value ie6 and removes those property checks, along with any classes *only* referenced from those rebind rules. Far

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to

Re: [gwt-contrib] GWT 2.7 release plan

https://code.google.com/p/google-web-toolkit/issues/detail?id=8716 is still open (and is a regression over GWT 2.6 and previous). Is this a reasonable item to get fixed? On Wednesday, October 1, 2014 2:23:43 PM UTC-5, Brian Slesinsky wrote: - Make sure sample apps work with DevMode

Re: [gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

that IE9 probably shouldn't be bound in that way (though it works, and may not work if differently bound)? Thanks for any clarification, Colin On Thu, Oct 2, 2014 at 11:05 AM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: Reverting the binding

Re: [gwt-contrib] Re: [2.7.0-SNAPSHOT] Bug in compilation with pretty mode

I also can reproduce this - when style is set to PRETTY, 4 of the 17 permutations starts off with the PRETTY setup code (from the linker?), then moves on to have all obfuscated (and sorted, etc) JS from the compilation process: var $wnd = $wnd || window.parent; var __gwtModuleFunction =

[gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

It looks like changes to a few rebind rules are generating some new logspam when any GWT app compiles. Specifically, I'm seeing FocusImpl and LayoutImpl, though its possible there are others I haven't seen yet. From the dynatable example we can see the FocusImpl spam: gwtc: [java]

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

The 'test runner' in this case is just the name of a regular module file, which happens to be used for running lots of tests, most of which look like EntryPoints. Nothing too magic going on here, and I've gotten this error by running modules for more 'normal' gwt apps as well, typically when I

[gwt-contrib] Re: -src in DevMode EntryPoint

Its possible that we can get away without an explicit way to add this (like classic Dev Mode has done so far), but -src makes multi-project development so much saner. No longer do you need to depend on your IDE to do the Right Thing (i.e. use *that* project as a jar from local maven repo, but

[gwt-contrib] IE11 property, if not permutation

As I'm sure everyone is aware, IE11 is making the navigator.useragent property significantly more useless than it already was, by having IE11 identify as 'Trident' rather than 'MSIE', and adding 'iPhone', 'Webkit', 'Android' and a few other obviously garbage strings. Check out

Re: [gwt-contrib] Snapshot and maven

For what its worth, we use a slightly different snapshot url: https://oss.sonatype.org/content/repositories/google-snapshots/. This appears to only contain snapshots instead of releases and snapshots. The /google/ url for whatever reason has a newer md5 and sha1 for the maven-metadata.xml file,

Re: GWT-client math vs. java-math

Thanks for posting about this Oskar. The radian/degree code can likely be changed (is that behavior specified as part of the Java spec?), though changing RPC serialization sounds like it would come with performance penalties - any comments there? What is your preferred method of resolving the

Re: Generation of permutations

You actually have three properties, not two - the 'extend-property' declaration means 'add these to the existing list of values'. Running the SOYC report will give you the full story on your properties and permutations (and lots more besides). Try a set-property line to specify not only 'add

<    1   2   3   4   5   >