Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 8:
Hi Goktug,
Being said that, rest assured, I wouldn't -1 for just not using it.
Good, good--sorry if I
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 8:
Hi Colin, the only approach in selecting classes is that these are what I'd
used so far, plus a few o
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 8:
doesn't fit into current IsXXX because if it was you wouldn't need
IsWidget2 :)
My take is that
Stephen Haberman has posted comments on this change.
Change subject: Optimize initializing fields at the top scope.
..
Patch Set 1:
(1 comment)
File dev/core/src/com
Stephen Haberman has posted comments on this change.
Change subject: Fix binary vs. internal variable names, remove unused Name
code.
..
Patch Set 1:
There are no semantic changes here, just updating variable names to
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3470
Change subject: Fix binary vs. internal variable names, remove unused Name
code.
..
Fix binary vs. internal variable names
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 8:
I went ahead and removed HasStyle, as it was a distraction. I also added
more methods to IsElement.
--
To
//gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Colin Alworth
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Goktug Gok
Stephen Haberman has posted comments on this change.
Change subject: Optimize initializing fields at the top scope.
..
Patch Set 1:
(1 comment)
File dev/core/src/com
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 7:
Okay, I think this is ready for another cursory review--I'm still mulling
about how to do the javadocs.
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3440
Change subject: Optimize initializing fields at the top scope.
..
Optimize initializing fields at the top scope.
Change-Id
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 7:
Replying to Goktug...
consistent naming convention throughout the SDKs
Agreed, of course. I see what you
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 6:
(9 comments)
File user/src/com/google/gwt/dom/client
31
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 7
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Colin Alworth
Gerrit-Rev
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 6:
(1 comment)
Hey guys, thanks for the comments. I'm out of town for a few days, but so
far they all make
Stephen Haberman has posted comments on this change.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Patch Set 9:
Huh. I knew this correct way was "slower" but I'm surpri
Stephen Haberman has submitted this change and it was merged.
Change subject: Remove unused, package-private FastStringMap.
..
Remove unused, package-private FastStringMap.
Change-Id: I8dd9f897a044ba53be5fc74fabb40a382b9ef119
Hey,
I wasn't quite sure, so figured I would ask: what's our policy on who
can give +2s? Is it any committer?
I assume so, but perhaps out of tradition, I've been assuming Googlers
would give +2s.
Well, and even if we are/have moved past the Google-only phase of GWT,
for now/awhile they will sti
Hey,
Not a big deal, but can someone +2 this code review:
https://gwt-review.googlesource.com/#/c/3280/
(Or -1 if it can't happen.)
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
> Sorry, IsWidget2. I didn't change IsWidget itself, of course.
Just mulling over options, it is too bad we won't get default methods
until Java 8, as otherwise they would be a nifty way of adding the
extra methods directly to the existing IsWidget itself, without
breaking any existing implementat
eType: newpatchset
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
eType: newpatchset
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
> What about IsWidget.Extended ?
That's actually pretty good.
Maybe IsWidget.Full...eh, just thinking that is shorter, and there are a
lot of places where I use the extended IsWidget type.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this messag
> 1) I added a new characteristic interface, HasStyle, that both
> IsElement and IsWidget extend
Sorry, IsWidget2. I didn't change IsWidget itself, of course.
I suppose that is another discussion point--in Tessell I could put the
"IsWidget with more methods than just asWidget" into a separate
org
: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors&q
> I'd like to submit a CL that moves the IsButton, IsListBox, etc.
Okay, I think this CL is at a pretty good state and ready for
high-level comments:
https://gwt-review.googlesource.com/#/c/3231
I have most of the common widgets covered, but not all--e.g. the older
panels I haven't used yet, so
: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors&q
errit-MessageType: newpatchset
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
--
http://groups.google.com/group/Google-Web-To
Hi Ed,
> FYI: the IsElement interfaces corresponds to issue 7497:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=7497
Oh, right, I forgot about that...well, maybe it will go in after
all. :-)
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You r
> If nobody else has any other concerns, I recommend you to start with
> an example interface to get early feedback and iterate from there.
So, I was going to start with just one, but copy/pasting them over and
changing the package name was pretty easy, so:
https://gwt-review.googlesource.com/#/
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3280
Change subject: Remove unused, package-private FastStringMap.
..
Remove unused, package-private FastStringMap.
Change-Id
Stephen Haberman has posted comments on this change.
Change subject: Ensures integer pixel values and adds getters for subpixel
values
..
Patch Set 2:
Per needing IE10 to test this, this may be a naive question, but I
> Let me check internally if we can find out if Johns concerns are
> valid so we might be able to implement this much simpler.
Cool; if having a patch to run through the Google submit/test queue
thing would help, let me know and I can put something together.
- Stephen
--
http://groups.google.c
Hi Daniel,
> I actually don't want to complicate the whole thing by throwing
> another thing into the discussion, so feel free to tell me off, but
> here I go:
No problem, what's another tangent? :-)
> If we construct these interfaces along the lines of todays widgets how
> would one add other t
> Does having the flag really make it that much more complicated?
It would not seem like it, but yes. :-)
Specifically passing the context down through the layers to the right
spot to say "do I serialize final fields?" took a bit--one of the first
patches that went by used a static field to avoi
> Just for the sake of correctness;
> You can still have similar stubs like you have today based on
> gwt-mockito (if you don't like mockito's 'expect' style).
Ah, sorry, my fault for not looking in to it more. Thanks for the
correction.
- Stephen
--
http://groups.google.com/group/Google-Web-T
> I don't have a good idea about what could break
I believe nothing would "break"--it's that final fields that were
previously not going over the wire would now go over the wire.
So, I guess technically that is a change in semantics--so it wouldn't
be like "oh, your GWT app fails to compile", mo
> as your framework does probably generate quite some code to make
> all these declarative binding features possible
No, actually--the bindings don't have any code generation to them,
either build-time or gwt-compile-time. They're pure Java, which means
they run in unit tests (it would suck if th
> If the former, then I understand it as mostly a mean to provide
> mocks/stubs/fakes for testing. How about gwt-mockito then?
> https://github.com/google/gwtmockito
This is tangenting a bit...but... :-)
I know everyone uses them, but IMO mocks are less than ideal for
testing UI code. With stub
> 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)?
Right, the former.
That doesn't mean the latter isn't worth doing, just that I think it's
a se
> 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 U
> If you create a Is* widget like IsButton you have to think about when
> to create the contains Widget variant like the Button class.
No, for the simple case (that I am proposing anyway), it's just:
class Button implements IsButton {
// nothing else changes
}
So no lazily creation/delegatio
Hi Jens,
> I would definitely prefer starting from zero without IE 6-8 in mind
> for new widgets.
With new widgets, definitely agree, I just think that's orthogonal to
adding interfaces for the existing widgets.
> So what would be the added benefit in terms of MVP?
In the Type 1 style of MVP, t
Hey,
So, there is a CL out there that I have kinda/sorta been shepherding
along to add support to GWT-RPC for final fields.
The current CL is kinda complicated right now, because we have at least
two flags about whether to turn final-fields on/off and also whether to
warn about it when it is off.
Hi,
Bringing this up again, but I'd like to submit a CL that moves the
IsButton, IsListBox, etc., interfaces I've made for Tessell into GWT
itself. IMO they would be useful to users doing MVP.
I believe the only recent objection was from Goktug, who wanted to take
the opportunity to make the widg
Stephen Haberman has posted comments on this change.
Change subject: Ensures integer pixel values and adds getters for subpixel
values
..
Patch Set 2:
@John I swore I remember reproducing this, where I saw something was
Stephen Haberman has posted comments on this change.
Change subject: Ensures integer pixel values and adds getters for subpixel
values
..
Patch Set 2:
Per John Tamplin's point, I agree it seems unlikely, but at the t
Stephen Haberman has posted comments on this change.
Change subject: Ensures integer pixel values and adds getters for subpixel
values
..
Patch Set 1:
(2 comments)
File
Stephen Haberman has posted comments on this change.
Change subject: Ensures integer pixel values and adds getters for subpixel
values
..
Patch Set 1:
FWIW I like Jen's 4th line as well (i.e. this CL).
--
To view,
> What problems has it caused?
I like the coding style as is, although it is a learning curve for
contributors. I believe I have the basics down now, but am never quite
sure.
I think it would be nice if getting them setup in both Eclipse and
IntelliJ was dead simple, instead of the current proce
Stephen Haberman has posted comments on this change.
Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..
Patch Set 4:
(1 comment)
File user/src
Stephen Haberman has submitted this change and it was merged.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Fix non-final field initializers running before the super cstr.
Previously
Stephen Haberman has posted comments on this change.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Patch Set 8:
Okay, I believe this is correct now. CompilerTest all passes. I had not
om/3030
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Leeroy Jenkins
Gerri
om/3030
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918
Gerrit-PatchSet: 7
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Leeroy Jenkins
Gerri
om/3030
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Leeroy Jenkins
Gerri
om/3030
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Leeroy Jenkins
Gerri
Stephen Haberman has posted comments on this change.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Patch Set 4:
Interesting, thanks, Roberto, I never would have thought of/found the
Stephen Haberman has submitted this change and it was merged.
Change subject: Have SimpleCheckBox implement HasValue.
..
Have SimpleCheckBox implement HasValue.
Bug: issue 4018
Change-Id
Stephen Haberman has submitted this change and it was merged.
Change subject: Avoid NPE in Timestamp.equals.
..
Avoid NPE in Timestamp.equals.
Bug: issue 6992
Change-Id: I044d3ddcabc5e41ed8fb9f871c35f700ff1d02eb
---
M user
Stephen Haberman has posted comments on this change.
Change subject: Avoid NPE in Timestamp.equals.
..
Patch Set 1:
Hi Daniel, no, I didn't know that--nifty!
So, I assume the workflow is to wait until 1 reviewer
Stephen Haberman has posted comments on this change.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Patch Set 4:
Okay, I added a test in CompilerTest--I had went looking for where to put
-Change-Id: I4c8ed0cd718a2188b33cc290fec6071c89be7918
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Ray Cromwell
Gerrit-Reviewer: Roberto Lublinerman
Gerrit-Reviewer: Stephen Haberman
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3011
Change subject: Avoid NPE in Timestamp.equals.
..
Avoid NPE in Timestamp.equals.
Bug: issue 6992
Change-Id
ephen Haberman
Gerrit-Reviewer: Goktug Gokdogan
Gerrit-Reviewer: Stephen Haberman
Gerrit-Reviewer: Thomas Broyer
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
Stephen Haberman has uploaded a new patch set (#3).
Change subject: Fix non-final field initializers running before the super
cstr.
..
Fix non-final field initializers running before the super cstr.
Previously, any field
Stephen Haberman has posted comments on this change.
Change subject: Fix non-final field initializers running before the super
cstr.
..
Patch Set 1:
(1 comment)
Commit
Stephen Haberman has uploaded a new patch set (#2).
Change subject: Fix non-final field initializers running before the super
cstr.
..
Fix non-final field initializers running before the super cstr.
Previously, any field
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3030
Change subject: Fix non-final field initializers running before the super
cstr.
..
Fix non-final field initializers running
Stephen Haberman has posted comments on this change.
Change subject: Have SimpleCheckBox implement HasValue, fixes 4018.
..
Patch Set 1:
(2 comments)
File user/src/com
view, visit https://gwt-review.googlesource.com/3010
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I790120198cb22ff38e676a303782b719f87083c6
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Hab
Stephen Haberman has uploaded a new change for review.
https://gwt-review.googlesource.com/3010
Change subject: Have SimpleCheckBox implement HasValue, fixes 4018.
..
Have SimpleCheckBox implement HasValue, fixes 4018
> It is slightly redundant, but I think it's nice to keep the option open to
> create other foo-discuss or bar-contrib mailing lists if the project grows and
> splits into independent subprojects.
True; I like being optimistic about future growth. :-)
> But I'd also like to avoid the name "gwt-u
> I think it could be beneficial to create a fourth group that is used
> by Gerrit so gwt-contrib doesn't get spammed.
I believe the idea is that gerrit can send out emails (either for
specific commits or you can subscribe to the entire project), so there
shouldn't be a need for a commits@ list.
> Also, since "google-web-toolkit-contributors" is incredibly long and no longer
> reflective of the projects name, it seems like a good time to fix that too.
Makes sense.
> gwt-disc...@gwtproject.org (formerly
> google-web-tool...@googlegroups.com )
In the spirit of friendly bikeshedding,
Hi Brian,
> I highly encourage doing an experiment and coming up with a demo.
> This is how innovation happens!
Agreed. I'll get back to poking at this and hopefully share something,
even embarassingly inadequate "soon". I had played with it awhile ago,
but it's such a huge task, that I got demot
> Hm maybe our app isn't large enough (~150 KLOC and growing) but we
> found DevMode to work pretty well in Firefox. Reloading the app is a
> matter of seconds and if you restart FireFox from time to time you
> can workaround the current memory leak.
Agreed, that is how I use it now.
> For me it
Hey,
Again preferring gwt-contrib for the discussion, even though this is
kind of a GWT steering/roap map discussion, but should we decide on an
official stance on JVM dev mode?
AFAICT, we've generally been considering it deprecated, given that
maintaining the plugins sucks, and the rest of the w
Hey,
Thought I would move this to gwt-contrib; during a compiler
improvements discussion in the last steering committee meeting, the
concept of having a dev mode run incrementally in Eclipse came up (e.g.
on save, reuses the existing AST), and Ray made a side comment
describing it as a "moonshot",
> Widgets written as current generation of GWT widgets in java vs
> native js widgets (e.g. closure)
Oh, cool. That sounds nifty. I assume that would benefit from
some of the future JS integration improvements? I hadn't thought
about that.
> I hit this problem in new Listbox style that is curren
> It should ideally work well with different native/non-native widget
> sources.
Just curious, but what do you mean by this?
> I have more radical ideas like introducing a pseudo-widget layer, so
> that developers can program around interface definitions (like Label,
> TextInput, Button, Link, S
> 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 skept
Hey,
I've brought this up before, but if I put together a patch that added
IsXxx interfaces for all/most of the widgets (IsTextBox, etc.),
assuming the patch was otherwise fine, would the GWT team/other
contributors tend towards +1, -1, or +/-0?
- Stephen
--
--
http://groups.google.com/group/G
> Chrome already has a protocol for most of this stuff, a wire-debugging
> protocol and source-maps.
Yes, I know.
My point was that FF/Chrome should use the same wire protocol.
That way if GPE ever learns to control the browser/JS debugger (e.g.
for SuperDevMode debugging while staying in Eclip
Hey,
I know I've been quiet on the GWT front lately, but I've really enjoyed
seeing all of the reviews/commits going by. Great stuff.
You've probably seen it, but there's a Mozilla post about next-gen dev
tools:
http://paulrouget.com/e/devtoolsnext
I posted a comment on it, but given we have GW
Stephen Haberman has posted comments on this change.
Change subject: Fix DOMImplIE9.isOrHasChild wrt non-HTMLElement elements
(e.g. SVGElement)
..
Patch Set 2: Code-Review+1
LGTM.
--
To view, visit https://gwt
Stephen Haberman has posted comments on this change.
Change subject: Fix DOMImplIE9.isOrHasChild wrt non-HTMLElement elements
(e.g. SVGElement)
..
Patch Set 1: Code-Review+1
(1 comment
> I've split out the GWT Developer Mode plugins source code into a
> separate Git repo in Gerrit
Cool!
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I hadn't seen this before, but they seem to be tackling
cross-browser/in-IDE debugging:
http://www.eclipse.org/webtools/jsdt/debug/
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
> I'm just throwing the idea here, in case anyone's interested in
> pursuing it, as an alternative to SuperDevMode, to continue running
> the code "in Java", debugged using your preferred Java debugger.
Thinking more about it, I think continuing to use the Java debugger (or
the existing ClientBro
Hey,
Since Thomas brought up changes to dev mode, I've been thinking about
how to implement an incremental dev mode.
After playing with SuperDevMode, it is better (no extensions/etc.), but
AFAICT it still starts over from "let's build a ResourceOracle", "now
let's build a TypeOracle", etc.
Seems
I agree this would be sexy and seems like where we should go, but it's
a long term thing. chromedevtools was only my list of things to
eventually (ha) play with.
I would think surely browsers would end up with a standard debug
protocol at some point--maybe Chrome/GWT could help drive that effort
> Chrome 24 introduced a bug, I'm working on a fix.
Awesome, thanks for the quick reply--I updated the issue appropriately.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Hey,
I'm (finally) playing with super dev mode and am not seeing source maps
working--I'm using Chrome 25 and saw this bug:
https://code.google.com/p/google-web-toolkit/issues/detail?id=7725
Is this affecting anyone else?
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contribu
http://gwt-code-reviews.appspot.com/1869804/diff/1/user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
File
user/test/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilderTest.java
(right):
http://gwt-code-reviews.appspot.com/1869804/diff/1/user/test/com/google
> It looks like he posted a complete patch almost three years ago. What
> do we need to do to get this into trunk?
https://developers.google.com/web-toolkit/makinggwtbetter#contributingcode
Generally, sign a CLA, and upload it to Rietveld; not sure who to pick
as the reviewer, I'll volunteer sky
> Or should I go ahead and propose a patch that deprecates it or even
> removes it?
That seems like a great idea to me; I would say go ahead and submit a
patch to remove it.
I suppose it is inevitable that some internal Google projects still use
it, but it would be nice to at least know, and I t
> But if we split things up into separate build targets (and associated jars)
> for different GWT modules, downstream projects can declare what they use.
Cool, makes sense, thanks for the sanity check.
> nor do we want to divide up the open source build into that many jars.
I dunno, I assumed w
> It doesn't explain the GWT-specific rules, but conceptually they're
> not that different from the cc_library rules, or a Makefile for that
> matter.
Just curious, but would stealing Lex Spoon's scala-gwt approach (writing
.jribble ASTs to disk, like .class files), allow the Google build
system
> There's no reason to rebuild every GWT app and run all the tests
> because one Java file in gwt.user changed that most people don't even
> use.
Just to understand more, how does avoiding ant solve the problem?
If RarelyUsedFile.java in gwt-user changes, then from my reading of the
blog post, t
101 - 200 of 520 matches
Mail list logo
