Ray, you can see the diffs by looking at internal code review. I updated a bunch of javadoc, tweaked Recompiler to deal with running with a different linker, and changed the regexps in WebServer to be slightly tighter and a bit more readable. But sure, basically the same.
http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD File dev/codeserver/BUILD (right): http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD#newcode1 dev/codeserver/BUILD:1: # Copyright 2012 Google Inc. All rights reserved. On 2012/06/05 01:05:21, cromwellian wrote:
Do we really want the BUILD file in the public repo?
I was using an out-of-date version of rietveld that didn't ignore these files. Fixed. http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java File dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java (right): http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java#newcode2 dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java:2: * Copyright 2011 Google Inc. On 2012/06/05 10:52:58, tbroyer wrote:
2012 ?
Well, I started on some of these files last year, so I'm going to leave it. http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java File dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java (right): http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java#newcode49 dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java:49: defaultProps.put("user.agent", "safari"); On 2012/06/05 10:52:58, tbroyer wrote:
This is just a "default" for the very first compilation, right? (but hard-coding things that way will prevent detecting the "right"
permutation
later on, no?)
Yes, this is just for the first compile and the output isn't intended to be run. Normally when you are running a separate server, the binding properties will be computed by the nocache.js script of the non-superdevmode version of the GWT app, and then they're saved in session storage, so we always compile the same permutation. However, I recently added support for running html files directly out of the Super Dev Mode code server (for an all-static GWT app where a separate server isn't needed). In that case, the initial compile *is* used, which is the wrong permutation if you're not using Safari or Chrome. And on the second compile, it will build all permutations, which is another bug. I'll be fixing this later. I'd like to see if there's a way to terminate the initial compile early and not output a permutation. It's a useful sanity check but shouldn't take too long. http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java File dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java (right): http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode134 dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:134: private class SourceFlag extends ArgHandler { On 2012/06/05 10:52:58, tbroyer wrote:
Why not use ArgHandlerDir?
This variant actually checks that the directory exists. (Probably ArgHandlerDir should be fixed, but I didn't want to get into that.) http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode148 dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:148: return "The root of a directory tree containing GWT source code to compile."; On 2012/06/05 16:15:35, cromwellian wrote:
On 2012/06/05 10:52:58, tbroyer wrote: > Does this mean SuperDevMode no longer loads sources from the
classpath?
It picks up from the classpath, but this directory shadows the
classpath. The
reason is, at least for Google, we always produce source-jars in our
internal
build system, and you can't 'edit' them. That is, when we launch
superdevmode,
it has the source, but it's been compiled and put into jars on the CP.
This
directory allows us to specify another location to look at, in
addition to the
classpath (which is the fallback)
For external users, it may not be needed, although I could see if
superdevmode
is launched from a Maven build you might run into the same issue.
Tweaked the help text a bit. http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java File dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java (right): http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode164 dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:164: // This is a GET because a bookmarklet can call it from a different origin (JSONP). On 2012/06/05 10:52:58, tbroyer wrote:
We should probably use CORS and XMLHttpRequest with a POST request,
instead of
JSON-P. The bookmarklet could handle XDomainRequest for IE8/9 and even
possibly
create an HTML form if we want to support IE6/7.
White-listing origins from command-line arguments would also add some
security. Yeah, CORS is better and I'm not too concerned about old browsers. Users would have to maintain the whitelist, though. If we want to wildcard hostnames (e.g. everything under corp.google.com), I think that requires a preflight request? http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode456 dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:456: private static String escapeHtmlCharacters(String line) { On 2012/06/05 10:52:58, tbroyer wrote:
Couldn't we use SafeHtml.fromString() here?
Currently, gwt-codeserver.jar only depends on gwt-dev.jar (and its dependencies) and I'd rather not add the dependency until it enables a more important feature. http://gwt-code-reviews.appspot.com/1727804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
