Comment by mirceade:
I know this must sound dumb:
If I have a pre-compiled core module and want to compile and add an
extension module on the fly (WITHOUT the core module's source code being
available) will this feature make it possible?
For more information:
Author: b...@google.com
Date: Wed May 27 06:31:38 2009
New Revision: 5474
Modified:
wiki/CssResource.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/CssResource.wiki
==
---
Author: b...@google.com
Date: Wed May 27 06:48:54 2009
New Revision: 5475
Added:
trunk/user/src/com/google/gwt/resources/rebind/context/MhtmlClientBundleGenerator.java
trunk/user/src/com/google/gwt/resources/rebind/context/MhtmlResourceContext.java
Modified:
Comment by rj...@google.com:
I'm afraid not. runAsync still relies on a monolithic compile.
For more information:
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/34821
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
BTW: can you confirm there's not a bug in the compiler's production of SOYC
artifacts?
On Wed, May 27, 2009 at 11:37 AM, sp...@google.com wrote:
LGTM
http://gwt-code-reviews.appspot.com/34821
--~--~-~--~~~---~--~~
Looks like the problem Adam was seeing was due to the dashboard not
finding the resources directory. I'm waiting to hear back from him to
confirm that. The above is unrelated.
On Wed, May 27, 2009 at 11:54 AM, Scott Blum sco...@google.com wrote:
BTW: can you confirm there's not a bug in the
So, I'm looking at our ant files, and trying to unwind several problems...
but I figure I'll ask what other people have as pet peeves, to see if there
are other games I should play, too.
Here's what's on my mind right now:
- If you run ant clean build; ant build, the second build should be
The $ vs. _ issue is weird to me, not sure what to make of it. I think I
know the files in question, and it's possible we're not getting any value
out of having .class files for inner classes checked in to version control..
we might can rename/nuke.
All the rest sounds great.
Last request would
My pain point:
I often want a trunk build of GWT to quickly test a patch. In this case I
only need the GWT build for the current platform whatever that is. I don't
need samples/demos nor do I need/want tests. I don't need a zipped up
distro, just the jars. Even javadocs would be optional. Of
What Fred's asking for is probably very similar to what would be needed to
run ant -f user/build.xml test.
On Wed, May 27, 2009 at 2:34 PM, Fred Sauer f...@allen-sauer.com wrote:
My pain point:
I often want a trunk build of GWT to quickly test a patch. In this case I
only need the GWT build
I think that's about what I'm hoping to make ant build become.
In terms of what's there today, Fred, have you tried the existing top-level
buildonly target? My complaint with that one is that it doesn't get the
.so/.dll files into a usable place, but if you manually drop them into
build/lib, I
+1 for Fred's use case.
And bonus points if I can specify an SVN revision at the command line
and have it check out that revision and build it in one step.
... on second thought, that might be more appropriate for a tool
separate from the build script, but I'll throw it out there anyway.
-
Separate tool. If the ant files that you start with are different than the
ones at the revision you're asking for, do you really want the ant launched
in the first revision-space to be driving?
On Wed, May 27, 2009 at 2:59 PM, Isaac Truett itru...@gmail.com wrote:
+1 for Fred's use case.
I have done something similar in the past. I wrote an Ant target to
update from CVS, build, and deploy an app. It *usually* worked all in
one space, which was good enough at the time. If you want to check out
revision x and then have revision x of build.xml run the actual build,
you could exec
Reviewers: amit,
Description:
The attached patch makes two changes to java.util.Date in an effort to
track down a very intermittent failure on IE. IE doesn't provide useful
stack traces for JS-initiated exceptions, so all we know is that jsdate
is uninitialized at some point when it is
http://gwt-code-reviews.appspot.com/33831/diff/1/2
File user/super/com/google/gwt/emul/java/util/Date.java (right):
http://gwt-code-reviews.appspot.com/33831/diff/1/2#newcode169
Line 169: @java.util.Date::checkJsDate()();
Should be th...@java.util.date:: and so on throughout.
Right. Both are supposed to be supported, and therefore should be tested,
but I don't think mine is the only system that balks at $, so as to avoid
quirky shell evaluation behavior. Thus the suggestion to go with overlays.
We could, alternatively, strongly prefer _ instead of $, and either not
18 matches
Mail list logo
