Committed at r5779.
If anyone is interested in testing this out, you can take a look at or
just inherit com.google.gwt.core.EmulateJsStack. Right now, this is
kind of a blunt instrument, but the control mechanism will be refined
with the addition of module property predicates.
--
Bob Vawter
Go
One thing this setup won't do is to minify the JS.
http://gwt-code-reviews.appspot.com/51814
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Reviewers: scottb,
Message:
Review requested.
Description:
Rhino's Node.getLineno() only returns useful data for JS statements.
This patch changes GWT's JsParser to provide statement-level line number
resolution for JsExpressions.
Please review this at http://gwt-code-reviews.appspot.com/51816
http://gwt-code-reviews.appspot.com/51816/diff/1/2
File dev/core/src/com/google/gwt/dev/js/JsParser.java (right):
http://gwt-code-reviews.appspot.com/51816/diff/1/2#newcode159
Line 159: SourceInfo toReturn = program.createSourceInfo(lineno,
parent.getFileName());
Will change.
http://gwt-code-re
LGTM
http://gwt-code-reviews.appspot.com/51817
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
> Is the concept of versioning something that belongs in the core GWT
> RPC code, or is this something better suited for an external library?
I have a design wave going on about how to add this to the new RPC
implementation. Here's a cruddy copy-and-paste of the current state
of the document.
> Also, will this be supported on methods themselves? For instance, can
> I mark a new method parameter as @Optional so that older clients don't
> need to provide it? Conversely, could we remove a parameter from a
> method and still support clients sending data with the old signature?
I could g
The deRPC code went into trunk a week or so ago, and no initial fires
have been reported. I'd like to get folks on GWTC to give it a
shakedown.
Quickstart (for vanilla configurations):
- Inherit com.google.gwt.rpc.Rpc in your gwt.xml file
- Change your remote service interfaces to extend
com
Reviewers: Lex, scottb,
Message:
Review requested.
@Lex, the implementation follows our IM discussion pretty much as
discussed.
Description:
This patch changes the way code-splitting and string interning is
performed on the JS AST to allow new strings to be introduced by
JsVisitors (such as Js
On Mon, Jul 27, 2009 at 7:37 PM, Ray Cromwell wrote:
> Woohoo! I assume this patch general purpose and would allow any of the Js
> optimization passes to introduce new string literals?
That's my expectation.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--
FYI: A complete re-merge of this, plus the stack trace code and IE event
handler fixup is at
http://gwt-code-reviews.appspot.com/54807
http://gwt-code-reviews.appspot.com/51820
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-
Reviewers: Ray Ryan, jgw,
Message:
Review requested.
Description:
This patch changes the way ImageBundleBuilder loads images to be able to
detect image files that contain multiple sub-images. Animated image
files do not undergo any transformation, but are emitted as-is via the
ResourceContext (
> http://gwt-code-reviews.appspot.com/51820/diff/1/8#newcode79
> Line 79: * fragments need only be downloaded once.
> I thought the LoadOrderOracle was a fine idea, so as to no longer
require
> passing in the JProgram. I guess it ran into some issue.
No issue; I just wanted to get all of the fun
On Tue, Jul 28, 2009 at 3:03 AM, futzi wrote:
> my first test showed, that
Thanks for the data.
Just to clarify, these payloads were only going from the server to the client?
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/g
On Mon, Aug 3, 2009 at 2:24 PM, Daniel Rice (דניאל רייס) wrote:
> That could still theoretically fail if removeEldestEntry did something
> weird that mutated the entries. But that seems pretty unlikely to be the
> case.
Which is basically the tension between application code (just make it
work
http://gwt-code-reviews.appspot.com/51830/diff/1/3
File layout/client/LayoutImpl.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode116
Line 116: return fixedRuler.getOffsetWidth() / 2.36;
Aren't these numbers subject to change based on display resolution?
http://gwt-code-r
> Anyways, it'd be great if this "feature" could be turned off (or just
> removed entirely). If the contributors group is the wrong place for
> this topic, don't hesitate to point me somewhere else.
You can pass -XdisableUpdateCheck to the tools to disable the update
check, which is only perform
LGTM, just one comment on the integration test.
http://gwt-code-reviews.appspot.com/51829/diff/1/3
File
user/test/com/google/gwt/dev/jjs/test/RunAsyncMetricsIntegrationTest.java
(right):
http://gwt-code-reviews.appspot.com/51829/diff/1/3#newcode199
Line 199: }
Check that the event queue is empt
Reviewers: Ray Ryan,
Message:
@Ray, does this take care of the issue you mentioned in IRC?
Description:
This patch does away with the need to write a callback just to be able
to discard the proxy object once the implementation has been loaded.
Please review this at http://gwt-code-reviews.appsp
Reviewers: scottb,
Message:
Review requested.
Description:
This is a convenience method for the permutation reduction work.
Please review this at http://gwt-code-reviews.appspot.com/56806
Affected files:
M dev/core/src/com/google/gwt/dev/util/collect/Sets.java
Index: dev/core/src/com/goog
Reviewers: bruce, scottb, Lex,
Message:
Review requested.
Description:
This patch allows and to be subjected
to conditions based on deferred-binding property values. The net effect
allows the developer to use a richer number of deferred-binding
properties without necessarily causing an explos
There's a related issue for ClassObjectTest. It is sensitive to
whether or not the compiler is in -XdisableClassMetadata mode.
I've wanted to add some kind of build information to the
GeneratorContext that would allow Generators to get the command-line
flags so generators can be sensitive to pre
This thread seems related to the one that Lex just started, that you
have user code which depends upon how the module was built.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~-
Reviewed the common, ie, and webkit code. LGTM
http://gwt-code-reviews.appspot.com/51834/diff/1/11
File plugins/common/ChooseTransportMessage.cpp (right):
http://gwt-code-reviews.appspot.com/51834/diff/1/11#newcode31
Line 31: * Receive an FatalError message from the channel (note that the
messa
Reviewers: bruce,
Message:
@Bruce, does the following work for you?
{
return location.search.indexOf('emulatedStack') != -1 ? 'true' :
'false';
}
Description:
This changes how JS stack emulation is enabled to take adv
Reviewers: kplatfoot, Ray Ryan,
Message:
Review requested.
Description:
This change declares the default filename suffixes on the resource types
instead of constants in the ResourceGenerators.
Please review this at http://gwt-code-reviews.appspot.com/61802
Affected files:
M user/src/com/goo
> Is there an appropriate more general home for this? I know I do it all
the time.
> Could it be an instance method on JClassType?
Moved to JClassType.findAnnotationInTypeHierarchy()
> For annotations marked @Inherited, would the super-crawl even be
necessary?
@Inherited doesn't work for superi
LGTM with nits.
http://gwt-code-reviews.appspot.com/62804/diff/1/2
File user/src/com/google/gwt/resources/css/GenerateCssAst.java (left):
http://gwt-code-reviews.appspot.com/62804/diff/1/2#oldcode695
Line 695:
Missing newline?
http://gwt-code-reviews.appspot.com/62804/diff/1/2
File user/src/co
Reviewers: mmendez, amirkashani,
Message:
Review requested.
Description:
This patch improves the performance of class selector obfuscation by
eliminating an excessive number of calls to Pattern.compile(). It also
cleans up unused-class-name error detection code.
The current delta is based on a
LGTM, though please clarify intent for HEAD requests.
http://gwt-code-reviews.appspot.com/56807/diff/1/2
File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
(right):
http://gwt-code-reviews.appspot.com/56807/diff/1/2#newcode450
Line 450: // to be safe, mark all non-GETs as non-c
Reviewers: scottb,
Message:
Review requested.
http://gwt-code-reviews.appspot.com/71802/diff/1/2
File dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java (left):
http://gwt-code-reviews.appspot.com/71802/diff/1/2#oldcode451
Line 451: jsoSubType.clearImplements();
This removal is necessary
> Good question, I have an 3.3 based Eclipse that's probably out of date now,
> and should probably update. But I was talking less about the particular
> settings, and more meant to suggest committing the reformat separately so as
> to make clear the syntactic vs. semantic change in the history.
Thanks for the review.
r6216 for the fix.
r6217 for the formatting changes.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Committed at r6218.
http://gwt-code-reviews.appspot.com/67807
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
> Does anyone know there's a reason Bob didn't do this in the first place?
Nobody asked for it. Since StyleInjector has stabilized, it would
make sense to add this convenience method. I'll send you a patch.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--
Reviewers: Ray Ryan,
Message:
Review requested.
Description:
This patch adds a convenience method to CssResource to ensure that the
contents of the CssResource have been injected into the DOM. The method
behaves as a one-shot; subsequent calls will have no effect.
Please review this at http://
Reviewers: Ray Ryan,
Message:
Review requested.
Description:
This patch switches CssResource to use strict behavior by default.
Please review this at http://gwt-code-reviews.appspot.com/75804
Affected files:
M user/src/com/google/gwt/resources/Resources.gwt.xml
M user/src/com/google/gwt/
Reviewers: Ray Ryan,
Message:
Review requested.
Description:
This patch adds a utility class will take a CssResource-compatible CSS
file and emit a Java interface declaration to standard out. This type
can be returned from a ClientBundle in strict mode.
CssResourceTest is updated to use an aut
CssResource offers a strict mode [1] which ensures that the emitted JS
/ CSS is as optimal as the system can make it by imposing a few
conditions on the input Java / CSS. Specifically, all CSS class
selectors must correspond with a Java accessor method, or the class
name must be explicitly exempt
> Have you thought about implementing ExternalDataSource?
> It looks like Flash doesn't like 'data:' URLs for creating Sound() objects.
> In gwt-voices I'd like to be able to use DataResource#getUrl() to get a
> strongly cacheable URL for my MP3 sound files.
I'd accept a patch to DataResourceGene
The idea of an IdResource is interesting. I have been looking for a good
sample resource type for a tutorial on extending ClientBundle. I think that
I will work this up while I'm travelling today.
--Bob (Android)
On Oct 5, 2009 12:12 PM, "Thomas Broyer" wrote:
On Mon, Oct 5, 2009 at 5:30 PM, R
I've attached a very simple implementation (with source) of an
IdResource that can be used with ClientBundle. You're welcome to
adapt it to your needs, but I don't see any additional ClientBundle
API making it into GWT 2.0 at this time.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~-
Here are three API design docs to address some common issues with the
GWT RPC system.
An API for passing an authentication token or session information
within RPC payloads, without having to add additional parameters to
each method or playing around with HTTP headers:
http://code.google.com/p/g
LGTM.
I think that using the timestamp of the ZipEntry is fine.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Why build support for Emma specifically? It seems like loading the
class bytes from the classpath if they're at least as new as the
source is a reasonable thing to do in the general case. Also, I think
that EmmaStrategy could be extracted into a general escape mechanism
for accessing external cla
LGTM.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Is anyone up for a review?
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Fri, Sep 5, 2008 at 7:45 AM, Joel Webber <[EMAIL PROTECTED]> wrote:
> 2. Can you actually use an arbitrary object as the key type? Based on the
> native put() implementation (map[key] = value), I'd guess not. I may be
> missing something, but I don't see any way to limit the key type as it's
>
All RpcByInterface is describing is a way to map an external type
(i.e. one not controlled by the developer) onto a type for which we
have a concrete implementation in the client code. The implementation
describes how the developer can inject the code that chooses an
alternate representation in
On Fri, Sep 5, 2008 at 1:00 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Okay, but there are very simpler ways to accomplish this?
Earlier drafts used to be more complicated. It's difficult to
simplify this without loss of generality.
- The current approach of declaring a sibling _CustomFieldS
On Tue, Sep 9, 2008 at 10:11 AM, Scott Blum <[EMAIL PROTECTED]> wrote:
> What was misplaced about this?
> By the way, we're at a point now where changes to the OOPHM branch need to
> be reviewed.
@John, are getting this working in your branch with the intent to
merge it into /branches/oophm later
Working on CssResource has shown a limitation in the Generator model
in that there are no provisions to accumulate state between
invocations of a Generator while rebinding a module. The general
problem with assuming stateful Generators is that the lifecycle and
invocation order of Generators ar
This patch against trunk allows multiple define-property tags for the
same deferred binding property. The second and subsequent definitions
of a property will override the allowable values and undo the effects
of any previous set-value tags. No change will be made to the
existing property-provide
It was the issue of repeated "restrict range of values" tags that made
me decide that define-property had a far more obvious semantic when
it's repeated. And, as a convenience to developers, you can add
additional property values with the one tag.
--
Bob Vawter
Google Web Toolkit Team
--~--~--
> - A redefinition of a deferred binding property does not invalidate a
> previous "set-property" declaration. If the previous "set-property"
> declaration is no longer a valid value in the redefined property, it is a
> static error.
This would be problematic if you wanted to redefine the proper
I agree with Bruce's design. The ability to widen an
initially-restricted set is compelling.
New thread that introduces non-deferred-binding properties:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/t/fa19b93ae079af12
--
Bob Vawter
Google Web Toolkit Team
--~--~-~-
> I am fine with that, but I do not think that set-property should be
> overloaded to both change the set of legal property values and to select the
> active property value depending on how many values are provided, nor do I
> think the current behavior of being able to set the active property val
On Thu, Sep 11, 2008 at 10:00 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> Could we list some examples, so that we can refer to this thread in the
> future to understand our motivations?
In summary, the motivation is to allow for properties that have no
well-defined set of possible values or th
On Thu, Sep 11, 2008 at 3:34 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> I swear I'm not just trying to be a pain. For things like this that don't
> quite merit a design doc ahead of time, these back-and-forth discussions
> have to happen during the code review.
No offense taken or annoyance g
The patch as is stands looks fine, but I think that it would be
worthwhile to investigate the use of our own GwtArray JS type:
function GwtArray(x) {if (x) this.concat(x);}
GwtArray.prototype = new Array();
GwtArray.prototype.toArray = ...;
// Set up other Java polymorphic dispatch functions on t
On Thu, Sep 11, 2008 at 7:02 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> gets another attribute called "values" that is mutually
> exclusive with "value":
>// set property 'foo' to
> the value 'a'
> OR
>// set property 'foo' the
> multi-value {'a', 'b', 'c'}
Is it the
> Namely:
> Hosted mode works fine but compiling tries to rebind twice (even
> though I only have
> one GWT.create()) and it can't create the printwriter because the
> class it is trying to write
> already exists. I guess I need a smarter generator. (?)
This is expected behavior. The generator
> 1) Avoiding slow-script warnings (SSWs) during RPC response deserialization
> - directly-evalable responses is one approach, to the extent that the
> response is written to be "break-up-able" (i.e. amenable to incremental
> commands); in the design doc, it does not appear that this crucial probl
core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
>trunk/user/test/com/google/gwt/i18n/I18N2Test.gwt.xml
>trunk/user/test/com/google/gwt/i18n/I18NTest.gwt.xml
>
> Log:
> Build fix: follow on to r3562.
>
> Review by: bo
Changes from previous patch:
- SourceInfos are now created only via JProgram and JsProgram.
Descendant collection is now a field in the program types.
- Optimized getRoots() call in SourceInfo
- Addressed nits
SourceInfo is now an abstract class with a protected constructor.
Each AST package
Thanks for the review. Subsequent ones should be relatively more
self-contained.
Committed at r3684.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~--
On Wed, Oct 1, 2008 at 9:23 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Sorry, patch attached this time.
LGTM.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~-
On Wed, Oct 1, 2008 at 12:24 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Want me to patch it back to JSIO trunk?
Sure.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~--
The attached conditionalizes J(s)Program.createSourceInfoSynthetic's
use of SourceInfo.findCaller() based on whether or not SOYC data is
being collected. On my MBP, this resulted in an approximate 2-3x
speedup compared with the current trunk
Diffstat:
jjs/ast/JProgram.java |5 3 + 2 -
> LGTM.
>
> With that big of a speedup, it looks worth, in the long term,
> eliminating the calls to findCaller() even when SOYC is enabled. If I
> understand the long-term plans, that was already intended anyway.
Committed at r3694. The calls to findCaller() will be removed, it's a
good-enough
On Thu, Oct 2, 2008 at 4:56 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> 1. Is there any reason to store all correlates as strings? The
I agree that the final API provided by the Correlation type should
be more structured than just a String, but I don't think that it
should hang on to the AST no
Would it be correct to summarize the chief blocking issue as needing
to reconsider the equals / compareTo / hashCode functions on
SourceInfo and Correlation?
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Too
The attached Java file shows a rough sketch of what the
CompilationAnalysis API might look like. The basic idea is to map
J(s)Nodes, SourceInfos, and Correlations onto a simplified API
suitable for building reports from. The inner interfaces would likely
be top-level types in a separate package
On Wed, Oct 15, 2008 at 1:39 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> Cool! LGTU.
Committed at r3760.
I'm going to follow up to this with a patch to pass in the caller of
makeChild() and makeSynthetic() since findCaller() was removed.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~-
This patch simplifies the XML parse error detection to not look for a
specific style applied to the error document.
Diffstat:
XMLParserImplSafari.java |61 + 5 - 0 !
1 file changed, 1 insertion(+), 5 deletions(-)
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~
[+GWTC]
On Thu, Oct 16, 2008 at 9:27 AM, Katharina Probst <[EMAIL PROTECTED]> wrote:
> Hi Bob,
>
> thanks for putting this together. I looked at the proposed
> xml format. I think all the important information is there, and it is
> quite clear.
>
> One thing that I noticed is that in order to g
Ok, I'll get started on the implementation. I'll keep the
CompilationAnalysis artifact type in the ext.linker package, but move
all of the inner interfaces into a sibling ext.soyc to keep the
namespace uncluttered.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~
> Your space bar is on a hair trigger.
> - Class comment of JsInliner has a semicolon starting a line
> - Method comment of JsInliner.InvocationCountingVisitor.removeCountsFor
> starts a line with a period.
Eclipse treats JavaDoc directives and html tags as acceptable places
for linebreaks. I
+1 to at least failing in a useful way.
LGTM.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Scott, Miguel, Kelly, and I sat down today to try to resolve some of
the problems with the existing "WAR" deployment design. Here is our
strawman proposal for how it should work in the future (we can go into
more detail on the rationale). Note that legacy mode would be
supported for 1.6 to mai
The cast to (T) is JsVisitor.accept() is necessary for javac 1.5.0_13
as shipped on OS X to compile the code.
Otherwise, LGTM.
What are your current thoughts on making runAsync work with XS and
SSO linkers, since they use function closures?
I'll follow up with an updated SOYC reports CL tha
> If that kind of functionality is not going to be implemented then I
> need at least an API to be able to encode a serializable object into a
> Form input field and output field. Since RPC already has serialisation/
> deserialisation it would be great if I could just reuse that code,
> without th
LGTM
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Tue, Nov 11, 2008 at 2:02 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> One big question: why a separate packer step? My naive understanding
> is that the point of a linker is to decide where the various bits of
> compiler output will go on disk. Is there a reason to discontinue
> that? It soun
I'm working on a srawman proposal for this; expect a copy later today.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Tue, Nov 11, 2008 at 2:39 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> Something tells me the packer proposal might be very useful. To
> package GWT apps for offline Android execution, Android demands that
> various artifacts be placed in precise directories on disk before
> being packaged in
On Fri, Nov 14, 2008 at 12:13 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 14, 2008 at 12:08 PM, BobV <[EMAIL PROTECTED]> wrote:
>>
>> The attached patch allows the CompilePerms phase of the compile to be
>> executed via pluggable strategies.
>
> What exactly is the reason we can't do the same here?
subclipse won't handle linked resources.
> Even if it is an
> issue, why would we not leave the files in an eclipse subdirectory and have
> interested users simply copy them to their trunk directory so we don't trash
> any other similarly n
Notes from an in-person conversation about making runAsync fragments
evaluate in the correct lexical scope and not pollute the global
namespace when using a cross-site linker.
The attached HTML demonstrates how the current code-gen form can be
used in an unmodified state if you're willing to disal
On Wed, Nov 19, 2008 at 9:32 AM, dflorey <[EMAIL PROTECTED]> wrote:
> Do I have to pass Constants, ImageBundle and ImmutableResourceBundle
> into a widget to achieve what I'm looking for or is there a smarter
> way?
My observation has been that most localized or resource-enable widgets
use a comb
Adding new resource types is done by defining a new interface that
derives from ResourcePrototype and annotating that new resource with
an @ResourceGeneratorType annotation. Take a look at TextResource as
an example of a simple resource type.
In the simplest case, you could define a new reso
LGTM
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Fri, Nov 21, 2008 at 1:37 PM, dflorey <[EMAIL PROTECTED]> wrote:
> 1. The CssResources are very powerfull but why do I have to write
> a .css file?
An early draft of CssResource with only class-based selectors used
Java annotations as the basis for providing the content of the rule.
It turne
The SOYC branch is ready to another review and merge to trunk. The
code can be reviewed with:
svn merge -r4025:HEAD
https://google-web-toolkit.googlecode.com/svn/changes/bobv/soyc-reports-r4205
Recent changes include:
- Addition of FileBackedObject that's passed around instead of plain
> Is there a plan to make Constants part of ImmutableResourceBundle?
Incubator r1252 includes a new resource type called GwtCreateResource.
interface GwtCreateResource extends ResourcePrototype {
T create();
}
interface Resources extends ImmutableResourceBundle {
// messages().create() invo
The attached patch against the 1.6 branch adds
EmittedArtifact.getLastModified() which is used to set the mtime on
files written to disk by the compiler. This resolves issue 2280.
The default implementation in the EmittedArtifact base class is
concrete to avoid breaking changes and always returns
On Thu, Dec 4, 2008 at 1:46 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Make that r4250 + r4251; I forgot to commit the calling code in
> StandardGeneratorContext.
LGTM
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Go
Notes:
- Having two servlet containers that need to be shipped with the
distribution seems like it will be problematic from the maintenance
perspective. We should aggressively deprecate the current entry
points if it is decided that we do want to ship both containers in
1.6.
- Several classes
On Fri, Dec 5, 2008 at 12:02 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> Here is an updated version that puts the deferred JS files for each
> permutation into a separate subdirectory of deferredjs. That is,
> where there used to be a '-', there is now a '/'.
LGTM.
--
Bob Vawter
Google Web Tool
LGTM
http://gwt-code-reviews.appspot.com/803
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
101 - 200 of 832 matches
Mail list logo
