[gwt-contrib] [google-web-toolkit] r6120 committed - Adds the htmlunit dependency to oophm. "ant dist-dev" passes...

[codesite-noreply]

Revision: 6120
Author: amitman...@google.com
Date: Thu Sep 10 17:10:13 2009
Log: Adds the htmlunit dependency to oophm. "ant dist-dev" passes

Patch by: amitmanjhi


http://code.google.com/p/google-web-toolkit/source/detail?r=6120

Modified:
  /branches/farewellSwt/dev/oophm/build.xml

===
--- /branches/farewellSwt/dev/oophm/build.xml   Thu Aug  6 18:57:54 2009
+++ /branches/farewellSwt/dev/oophm/build.xml   Thu Sep 10 17:10:13 2009
@@ -30,6 +30,8 @@

  
  
+
+

  


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6119 committed - Commiting the initial version of the HtmlUnit plugin. Many tests, incl...

[codesite-noreply]

Revision: 6119
Author: amitman...@google.com
Date: Thu Sep 10 16:26:01 2009
Log: Commiting the initial version of the HtmlUnit plugin. Many tests,  
including all
of EmulSuite, pass. Remaining work:
(i) Test with other GwtTests and fix.
(ii) Re-factor the code.
(iii) Garbage collection of javaObject references.
(iv) Minor todos like implementation of toString.

Patch by: amitmanjhi
Review (and some pair-programming) by: jat (TBR)


http://code.google.com/p/google-web-toolkit/source/detail?r=6119

Added:
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelClient.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/HostedModePluginObject.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/HtmlUnitSessionHandler.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/JavaObject.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/ServerMethods.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/SessionData.java
   
/branches/farewellSwt/user/src/com/google/gwt/junit/RunStyleHtmlUnitHosted.java
Modified:
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannel.java
   
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/JsValueOOPHM.java
  /branches/farewellSwt/eclipse/dev/oophm/.classpath
  /branches/farewellSwt/eclipse/user/.classpath
  /branches/farewellSwt/user/build.xml
  /branches/farewellSwt/user/src/com/google/gwt/junit/JUnitShell.java
  /branches/farewellSwt/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java

===
--- /dev/null
+++  
/branches/farewellSwt/dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelClient.java
   
Thu Sep 10 16:26:01 2009
@@ -0,0 +1,201 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may  
not
+ * use this file except in compliance with the License. You may obtain a  
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,  
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations  
under
+ * the License.
+ */
+package com.google.gwt.dev.shell;
+
+import com.google.gwt.core.ext.TreeLogger;
+import  
com.google.gwt.dev.shell.BrowserChannel.SessionHandler.ExceptionOrReturnValue;
+import com.google.gwt.dev.util.log.PrintWriterTreeLogger;
+
+import java.io.IOException;
+import java.net.Socket;
+
+/**
+ * Implementation of the BrowserChannel for the client side.
+ *
+ */
+public class BrowserChannelClient extends BrowserChannel {
+
+  private static final int PROTOCOL_VERSION = 2;
+  private final HtmlUnitSessionHandler htmlUnitSessionHandler;
+  private final PrintWriterTreeLogger logger = new PrintWriterTreeLogger();
+  private final String moduleName;
+  private final String tabKey;
+  private final String sessionKey;
+  private final String url;
+  private final String versionString;
+  private boolean connected = false;
+
+  public BrowserChannelClient(String addressParts[], String url,
+  String sessionKey, String moduleName, String versionString,
+  HtmlUnitSessionHandler htmlUnitSessionHandler) throws IOException {
+super(new Socket(addressParts[0], Integer.parseInt(addressParts[1])));
+connected = true;
+this.url = url;
+this.sessionKey = sessionKey;
+this.moduleName = moduleName;
+this.tabKey = ""; // TODO(jat): update when tab support is added.
+this.versionString = versionString;
+logger.setMaxDetail(TreeLogger.WARN);
+logger.log(TreeLogger.SPAM, "BrowserChannelClient, versionString: "
++ versionString);
+this.htmlUnitSessionHandler = htmlUnitSessionHandler;
+  }
+
+  public boolean disconnectFromHost() throws IOException {
+logger.log(TreeLogger.DEBUG, "disconnecting channel " + this);
+if (!isConnected()) {
+  logger.log(TreeLogger.DEBUG,
+  "Disconnecting already disconnected channel " + this);
+  return false;
+}
+new QuitMessage(this).send();
+endSession();
+connected = false;
+return true;
+  }
+
+  public boolean isConnected() {
+return connected;
+  }
+
+  // TODO (amitmanjhi): refer the state (message?) transition diagram
+  /**
+   * returns true iff execution completes normally.
+   */
+  public boolean process() throws IOException, BrowserChannelException {
+if (!init()) {
+  disconnectFromHost();
+  return false;
+}
+logger.log(TreeLogger.DEBUG, "sending " + MessageType.LOAD_MODULE
++ " message, userAgent: " + htmlUnitSessionHandler.getUserAgent());
+ReturnMessage returnMessage = null;
+synchronized (htmlUnitSessionHandler.getHtmlPage()) {
+  new LoadModuleMessage(this, url, tabKey, sessionKey, moduleName,

[gwt-contrib] [google-web-toolkit] r6118 committed - Checking in the htmlunit 2.5 sources, for easier debugging

[codesite-noreply]

Revision: 6118
Author: amitman...@google.com
Date: Thu Sep 10 16:21:30 2009
Log: Checking in the htmlunit 2.5 sources, for easier debugging
http://code.google.com/p/google-web-toolkit/source/detail?r=6118

Added:
  /tools/lib/htmlunit/htmlunit-2.5-sources.jar
  /tools/lib/htmlunit/htmlunit-core-js-2.5-sources.jar

===
--- /dev/null   
+++ /tools/lib/htmlunit/htmlunit-2.5-sources.jarThu Sep 10 16:21:30 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /tools/lib/htmlunit/htmlunit-core-js-2.5-sources.jarThu Sep 10  
16:21:30 2009
Binary file, no diff available.

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6117 committed - Duh!

[codesite-noreply]

Revision: 6117
Author: amitman...@google.com
Date: Thu Sep 10 16:06:57 2009
Log: Duh!


http://code.google.com/p/google-web-toolkit/source/detail?r=6117

Added:
  /branches/farewellSwt
Deleted:
  /branches/fairwellSwt


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6116 committed - A straight copy from tr...@6001. This branch will contain the work don...

[codesite-noreply]

Revision: 6116
Author: amitman...@google.com
Date: Thu Sep 10 16:03:12 2009
Log: A straight copy from tr...@6001. This branch will contain the work  
done on
htmlunit oophm plugin and on removing the Swt dependency.


http://code.google.com/p/google-web-toolkit/source/detail?r=6116

Added:
  /branches/fairwellSwt


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[Joel Webber]

W00t, thanks. Looking forward to using this.Thanks for doing this review,
Lex.

On Thu, Sep 10, 2009 at 4:36 PM,  wrote:

>
> On 2009/09/10 19:54:05, Ray Ryan wrote:
>
>
> Committed r6114
>
> http://gwt-code-reviews.appspot.com/64812
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6115 committed - Add 48x48 icon.

[codesite-noreply]

Revision: 6115
Author: j...@google.com
Date: Thu Sep 10 15:17:21 2009
Log: Add 48x48 icon.

http://code.google.com/p/google-web-toolkit/source/detail?r=6115

Added:
  /trunk/plugins/npapi/prebuilt/gwtdmp/gwt48.png
Modified:
  /trunk/plugins/npapi/prebuilt/gwtdmp/manifest.json

===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/gwt48.png  Thu Sep 10 15:17:21 2009
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwtdmp/manifest.json  Thu Sep 10 11:52:42  
2009
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/manifest.json  Thu Sep 10 15:17:21  
2009
@@ -5,6 +5,7 @@
"icons": {
  "16": "gwt16.png",
  "32": "gwt32.png",
+"48": "gwt48.png",
  "64": "gwt64.png",
  "128": "gwt128.png"
},

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6114 committed - Introduces inline styles to ui.xml files, completing...

[codesite-noreply]

Revision: 6114
Author: rj...@google.com
Date: Thu Sep 10 13:35:35 2009
Log: Introduces inline styles to ui.xml files, completing
http://code.google.com/p/google-web-toolkit/issues/detail?id=3984 to a
first approximation.

Only CssResource works so far, via . @Sprite won't work
until  is implemented, and  is still needed as well.

Reviewed by: spoon

http://code.google.com/p/google-web-toolkit/source/detail?r=6114

Modified:
  /trunk/user/src/com/google/gwt/uibinder/rebind/UiBinderParser.java
  /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java
   
/trunk/user/src/com/google/gwt/uibinder/rebind/model/ImplicitClientBundle.java
   
/trunk/user/src/com/google/gwt/uibinder/rebind/model/ImplicitCssResource.java
  /trunk/user/src/com/google/gwt/uibinder/sample/client/WidgetBasedUi.css
  /trunk/user/src/com/google/gwt/uibinder/sample/client/WidgetBasedUi.java
  /trunk/user/src/com/google/gwt/uibinder/sample/client/WidgetBasedUi.ui.xml
  /trunk/user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java

===
--- /trunk/user/src/com/google/gwt/uibinder/rebind/UiBinderParser.java  Wed  
Sep  9 10:35:52 2009
+++ /trunk/user/src/com/google/gwt/uibinder/rebind/UiBinderParser.java  Thu  
Sep 10 13:35:35 2009
@@ -20,6 +20,7 @@
  import com.google.gwt.core.ext.typeinfo.JMethod;
  import com.google.gwt.core.ext.typeinfo.TypeOracle;
  import com.google.gwt.resources.client.CssResource;
+import com.google.gwt.uibinder.parsers.NullInterpreter;
  import com.google.gwt.uibinder.rebind.messages.MessagesWriter;
  import com.google.gwt.uibinder.rebind.model.ImplicitClientBundle;
  import com.google.gwt.uibinder.rebind.model.ImplicitCssResource;
@@ -39,6 +40,7 @@
private final MessagesWriter messagesWriter;
private final FieldManager fieldManager;
private final ImplicitClientBundle bundleClass;
+  private final JClassType cssResourceType;

public UiBinderParser(UiBinderWriter writer, MessagesWriter  
messagesWriter,
FieldManager fieldManager, TypeOracle oracle,
@@ -48,7 +50,8 @@
  this.messagesWriter = messagesWriter;
  this.fieldManager = fieldManager;
  this.bundleClass = bundleClass;
-  }
+this.cssResourceType =  
oracle.findType(CssResource.class.getCanonicalName());
+ }

/**
 * Parses the root UiBinder element, and kicks off the parsing of the  
rest of
@@ -56,7 +59,7 @@
 */
public String parse(XMLElement elem) throws UnableToCompleteException {
  // TODO(rjrjr) Clearly need to break these find* methods out into  
their own
-// parsers, need registration scheme for ui binder's own parsers
+// parsers, an so need a registration scheme for uibinder-specific  
parsers
  findStyles(elem);
  findResources(elem);
  messagesWriter.findMessagesConfig(elem);
@@ -66,8 +69,16 @@

private JClassType consumeCssResourceType(XMLElement elem)
throws UnableToCompleteException {
-JClassType publicType = consumeTypeAttribute(elem);
-JClassType cssResourceType =  
oracle.findType(CssResource.class.getCanonicalName());
+String typeName = elem.consumeAttribute("type", null);
+if (typeName == null) {
+  return cssResourceType;
+}
+
+JClassType publicType = oracle.findType(typeName);
+if (publicType == null) {
+  writer.die("In %s, no such type %s", elem, typeName);
+}
+
  if (!publicType.isAssignableTo(cssResourceType)) {
writer.die("In %s, type %s does not extend %s", elem,
publicType.getQualifiedSourceName(),
@@ -131,13 +142,18 @@
}

private void createStyle(XMLElement elem) throws  
UnableToCompleteException {
-// Won't be required for long
-String source = elem.consumeRequiredAttribute("source");
+String body =  elem.consumeInnerText(new NullInterpreter());
+if (body.length() > 0 && elem.hasAttribute("source")) {
+  writer.die("In %s, cannot use both a source attribute and inline css  
text.", elem);
+}
+
+String source = elem.consumeAttribute("source");
  String name = elem.consumeAttribute("field", "style");
  JClassType publicType = consumeCssResourceType(elem);

  ImplicitCssResource cssMethod = bundleClass.createCssResource(name,  
source,
-publicType);
+publicType, body);
+
  FieldWriter field = fieldManager.registerFieldOfGeneratedType(
  cssMethod.getPackageName(), cssMethod.getClassName(),
  cssMethod.getName());
===
--- /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java  Thu Sep 
  
3 16:03:13 2009
+++ /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java  Thu Sep 
 
10 13:35:35 2009
@@ -1,12 +1,12 @@
  /*
   * Copyright 2008 Google Inc.
- *
+ *
   * Licensed under the Apache License, Version 2.0 (the "License"); you may  
not
   * use this file except in compliance with the License. You may obtain a  
copy of
   * the License at
- *
+ *
   * http://www.apache.org/licenses/LICENSE-2.

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[rjrjr]

On 2009/09/10 19:54:05, Ray Ryan wrote:


Committed r6114

http://gwt-code-reviews.appspot.com/64812

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[spoon]

Yes, I've been using LGTM with comments to mean go ahead and commit, and
I'll look at the changes afterward.


http://gwt-code-reviews.appspot.com/64812/diff/1/5
File
user/src/com/google/gwt/uibinder/rebind/model/ImplicitCssResource.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/5#newcode138
Line 138: * this package
On 2009/09/10 19:51:09, Ray Ryan wrote:>
> I think you just implied that I should change the UiBinder code in
general to
> start using ResourceOracle? If so, I'll put that on the todo list.

It looks like a good idea to me, just because it looks helpful to have a
single API defining what resources come along with the user's code.

http://gwt-code-reviews.appspot.com/64812/diff/1/9
File user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/9#newcode281
Line 281: widgetUi.totallyPrivateStyleSpan.getClassName().length() > 0);
Okay!  It was just a thought.  If there's not an easy way to dig the
styling back out of the DOM, then so be it.

http://gwt-code-reviews.appspot.com/64812

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[rjrjr]

http://gwt-code-reviews.appspot.com/64812

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[rjrjr]

Thanks Lex.

Responses inline. I fixed the comment and am stumped on the test, would
love to hear ideas. I'll take your LGTM as an invitation to submit w/the
test as is.


http://gwt-code-reviews.appspot.com/64812/diff/1/5
File
user/src/com/google/gwt/uibinder/rebind/model/ImplicitCssResource.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/5#newcode67
Line 67: * file rather than look load a resource.
On 2009/09/10 18:12:43, Lex wrote:
> Sounds just great.

> "rather than look load" -->  "rather than load"


Done.

http://gwt-code-reviews.appspot.com/64812/diff/1/5#newcode138
Line 138: * this package
It looks like it starts with ResourceOracle and then tries the thread
class loader if that fails. Dunno why.

I think you just implied that I should change the UiBinder code in
general to start using ResourceOracle? If so, I'll put that on the todo
list.

http://gwt-code-reviews.appspot.com/64812/diff/1/9
File user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/9#newcode281
Line 281: widgetUi.totallyPrivateStyleSpan.getClassName().length() > 0);
Ideally I'd look at the computed style rather than the class name. We
don't offer an api for that, and I suspect it's not possible or
non-trivial cross browser. (Love to hear that I'm wrong.)

I've been racking my brain for an alternative and I don't see a way to
do it.

I'm testing styles that are only accessible via methods on a generated
interface, that's the whole point. To see them for real I'd have to
declare these methods in a non-generated interface implemented by
ui:style, but that defeats the purpose of the test.

http://gwt-code-reviews.appspot.com/64812

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add more HtmlUnit platforms/browsers testings

[Frank Lin]

Should the compiled JS code be browser dependent? With multiple threads, it
ran out of memory for me couple times. Lastly, if one browser failed, it
stops the rest of the tests.

On Wed, Sep 9, 2009 at 5:02 PM, Amit Manjhi  wrote:

> For now, it seems fine. It is the same issue when running multiple browsers
> simultaneously during remoteweb or selenium tests.
>
>
> On Wed, Sep 9, 2009 at 1:45 PM, Frank Lin  wrote:
>
>> Just one issue: is it okay to use test.out for all platforms if using
>> '-htmlunit FF3, FF2, IE6, IE7'?
>>  test.out="${junit.out}/${build.host.platform}-htmlunit-web-mode"
>>
>> On Wed, Sep 9, 2009 at 11:40 AM, Amit Manjhi wrote:
>>
>>>
>>>
>>> On Wed, Sep 9, 2009 at 11:19 AM, Frank Lin  wrote:
>>>
 Hi Amit,


 On Wed, Sep 9, 2009 at 9:25 AM,  wrote:

> Hi Frank,
>
> Instead of having individual ant commands for each browser emulation,
> it
> would be better to test all the browsers in parallel using -htmlunit
> FF3, FF2, IE6, IE7.
>
> I would suggest more ant targets rather let ant optimize the
 parallelism since blaze might be able to shard them better. We might need
 Freeland's expertise on that.

>>>
>>> When all browsers are specified, the parallelism is at the JVM level, not
>>> at the ant level. A separate HtmlUnit thread is started to emulate each
>>> browser.
>>>
>>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6113 committed - Keep expando ID in sync with our object table by removing the property...

[codesite-noreply]

Revision: 6113
Author: j...@google.com
Date: Thu Sep 10 11:55:16 2009
Log: Keep expando ID in sync with our object table by removing the property  
when
the object is removed from our table.

http://code.google.com/p/google-web-toolkit/source/detail?r=6113

Modified:
  /trunk/plugins/npapi/ScriptableInstance.cpp

===
--- /trunk/plugins/npapi/ScriptableInstance.cpp Wed Sep  9 14:57:53 2009
+++ /trunk/plugins/npapi/ScriptableInstance.cpp Thu Sep 10 11:55:16 2009
@@ -362,7 +362,12 @@
Debug::log(Debug::Debugging) << "freeValue(#ids=" << idCount << ")" <<  
Debug::flush;
for (int i = 0; i < idCount; ++i) {
  Debug::log(Debug::Spam) << " id=" << ids[i] << Debug::flush;
-localObjects.free(ids[i]);
+NPObject* obj = localObjects.get(ids[i]);
+if (!NPN_RemoveProperty(getNPP(), obj, gwtId)) {
+  Debug::log(Debug::Error) << "Unable to remove GWT ID from object "  
<< ids[i] << Debug::flush;
+} else {
+  localObjects.free(ids[i]);
+}
}
  }


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6112 committed - Delete old cruft, rearrange directory structure to better build the Ch...

[codesite-noreply]

Revision: 6112
Author: j...@google.com
Date: Thu Sep 10 11:52:42 2009
Log: Delete old cruft, rearrange directory structure to better build the  
Chrome
plugin with just what is needed.

http://code.google.com/p/google-web-toolkit/source/detail?r=6112

Added:
  /trunk/plugins/npapi/prebuilt/gwtdmp
  /trunk/plugins/npapi/prebuilt/gwtdmp/WINNT_x86-msvc
  /trunk/plugins/npapi/prebuilt/gwtdmp/gwt128.png
  /trunk/plugins/npapi/prebuilt/gwtdmp/gwt16.png
  /trunk/plugins/npapi/prebuilt/gwtdmp/gwt32.png
  /trunk/plugins/npapi/prebuilt/gwtdmp/gwt64.png
  /trunk/plugins/npapi/prebuilt/gwtdmp/manifest.json
Deleted:
  /trunk/plugins/npapi/prebuilt/extension
  /trunk/plugins/npapi/prebuilt/gwt128.png
  /trunk/plugins/npapi/prebuilt/gwt16.png
  /trunk/plugins/npapi/prebuilt/gwt32.png
  /trunk/plugins/npapi/prebuilt/gwt64.png
  /trunk/plugins/npapi/prebuilt/manifest.json
  /trunk/plugins/npapi/prebuilt/oophm.xpi
  /trunk/plugins/npapi/prebuilt/winnt_x86-msvc
Modified:
  /trunk/plugins/npapi/VisualStudio/npapi-plugin.vcproj
  /trunk/plugins/npapi/prebuilt/gwtdmp/WINNT_x86-msvc/npOOPHM.dll
  /trunk/plugins/npapi/prebuilt/gwtdmp.crx

===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/gwt128.png Thu Sep 10 11:52:42 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/gwt16.png  Thu Sep 10 11:52:42 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/gwt32.png  Thu Sep 10 11:52:42 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/gwt64.png  Thu Sep 10 11:52:42 2009
Binary file, no diff available.
===
--- /dev/null
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/manifest.json  Thu Sep 10 11:52:42  
2009
@@ -0,0 +1,14 @@
+{
+  "name": "GWT Development Mode Plugin",
+  "version": "0.9.0",
+  "description": "A plugin to enable debugging with GWT's Development  
Mode",
+  "icons": {
+"16": "gwt16.png",
+"32": "gwt32.png",
+"64": "gwt64.png",
+"128": "gwt128.png"
+  },
+  "plugins": [
+{ "path": "WINNT_x86-msvc/npOOPHM.dll", "public": true }
+  ]
+}
===
--- /trunk/plugins/npapi/prebuilt/gwt128.pngThu Sep 10 07:24:58 2009
+++ /dev/null   
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwt16.png Thu Sep 10 07:24:58 2009
+++ /dev/null   
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwt32.png Thu Sep 10 07:24:58 2009
+++ /dev/null   
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwt64.png Thu Sep 10 07:24:58 2009
+++ /dev/null   
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/manifest.json Thu Sep 10 07:24:58 2009
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "name": "GWT Development Mode Plugin",
-  "version": "0.9.0",
-  "description": "A plugin to enable debugging with GWT's Development  
Mode",
-  "icons": {
-"16": "gwt16.png",
-"32": "gwt32.png",
-"64": "gwt64.png",
-"128": "gwt128.png"
-  },
-  "plugins": [
-{ "path": "winnt_x86-msvc/npOOPHM.dll", "public": true }
-  ]
-}
===
--- /trunk/plugins/npapi/prebuilt/oophm.xpi Mon Aug  3 08:30:11 2009
+++ /dev/null   
File is too large to display a diff.
===
--- /trunk/plugins/npapi/VisualStudio/npapi-plugin.vcproj   Wed Sep  9  
08:52:07 2009
+++ /trunk/plugins/npapi/VisualStudio/npapi-plugin.vcproj   Thu Sep 10  
11:52:42 2009
@@ -63,7 +63,7 @@
Name="VCLinkerTool"
AdditionalDependencies="ws2_32.lib"
ShowProgress="2"
-   
OutputFile="$(ProjectDir)\..\prebuilt\WINNT_x86-msvc\npOOPHM.dll"
+
OutputFile="$(ProjectDir)\..\prebuilt\gwtdmp\WINNT_x86-msvc\npOOPHM.dll"
LinkIncremental="1"

ModuleDefinitionFile="$(ProjectDir)\..\npOOPHM.def"
GenerateDebugInformation="true"
===
--- /trunk/plugins/npapi/prebuilt/winnt_x86-msvc/npOOPHM.dllWed Sep  9  
14:57:53 2009
+++ /trunk/plugins/npapi/prebuilt/gwtdmp/WINNT_x86-msvc/npOOPHM.dll Thu Sep 
 
10 11:52:42 2009
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwtdmp.crxWed Sep  9 15:45:43 2009
+++ /trunk/plugins/npapi/prebuilt/gwtdmp.crxThu Sep 10 11:52:42 2009
Binary file, no diff available.

--~--~-~--~~~---~--~~
http://groups.goog

[gwt-contrib] Re: GWT Incubator compatibility policy

[Ray Ryan]

If you're after guarantees I guess that would be 1686, the one that the 1.7
jar was cut from (gwt-incubator-july-14-2009.jar). Looking at the svn
history, nothing has actually changed in the code from that one to the
removal of StyleInjector. It's all wiki edits and such since then.

On Thu, Sep 10, 2009 at 8:46 AM, jay  wrote:

>
> So...as of right now, what is the *last* version of gwt-incubator that
> is guaranteed to work with GWT 1.7? Is it safe to assume that it is
> the version immediately prior to the removal of StyleInjector?
>
> thanks,
>
> jay
>
> On Sep 10, 8:28 am, Isaac Truett  wrote:
> > [oops - +gwtc]
> >
> > Hi, Ray,
> >
> > I appreciate the drive to move forward and I applaud jumping on
> > opportunities to remove redundant code.
> >
> > The reason this policy was important, to me at least, is that it
> > provided a baseline to work against. The code in the incubator can be
> > very useful (I use PagingScrollTable extensively and used DatePicker
> > from incubator before it graduated) but it's also risky because the
> > code is still experimental and subject to change. The assurance that
> > those changes would be compatible with a packaged and released GWT
> > build (even just a milestone) meant that I could build incubator from
> > trunk and pick up the latest features and bugfixes as long as my
> > project tracked the latest GWT build. Because of the GWT policies on
> > deprecation and backwards compatibility, this has been fairly easy in
> > practice. As it stands now, incubator will not compile except against
> > GWT trunk, which is also notoriously unstable (it wasn't building as
> > recently as last night, which I see was corrected this morning). This
> > presents a much higher risk for those of us using incubator code.
> >
> > It also becomes harder to work on the incubator itself when it has to
> > compile against GWT trunk. I wanted to look into issue #267 last night
> > and I was stymied by GWT trunk not being in a buildable state. Not an
> > insurmountable obstacle, but one that seems unnecessary to me.
> >
> > - Isaac
> >
> >
> >
> > On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
> > > Hey, Isaac.
> > > That policy has proven very difficult to live with. (And to tell you
> the
> > > truth I forgot about it.)
> > > The reasoning here was that we have released incubator jars that work
> with
> > > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it
> prove
> > > necessary to go back and do so we can go back and branch.
> > > In the meantime, we were faced bugs due to FastTree in particular being
> tied
> > > to the old StyleInjector while new development was moving to the
> version in
> > > GWT.  We saw the opportunity to delete redundant code and took it.
> > > Is this going to cause problems for anyone?
> > > rjrjr
> >
> > > On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett 
> wrote:
> >
> > >> Last year, Emily stated that it would compile against the "latest
> > >> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
> > >> I've seen, so under the policy from last year StyleInjector should not
> > >> have been removed in revisions 1712-1715.
> >
> > >> So, what's the current policy for incubator trunk compatibility?
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[spoon]

LGTM.  One comment typo, one question about a possible extra test.


http://gwt-code-reviews.appspot.com/64812/diff/1/5
File
user/src/com/google/gwt/uibinder/rebind/model/ImplicitCssResource.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/5#newcode67
Line 67: * file rather than look load a resource.
Sounds just great.

"rather than look load" -->  "rather than load"

http://gwt-code-reviews.appspot.com/64812/diff/1/5#newcode138
Line 138: * this package
I don't know what else that utility does, but if nothing else loading
from ResourceOracle has the advantage of centralizing the choice of
class loader.

http://gwt-code-reviews.appspot.com/64812/diff/1/9
File user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
(right):

http://gwt-code-reviews.appspot.com/64812/diff/1/9#newcode281
Line 281: widgetUi.totallyPrivateStyleSpan.getClassName().length() > 0);
How hard would it be to test that the style contents are sane?

http://gwt-code-reviews.appspot.com/64812

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT Incubator compatibility policy

[Isaac Truett]

I can't argue with that. I was not aware that incubator was winding to
a close. I thought it was just in a lull prior to the 2.0 milestone,
as it had been before other releases. With that new perspective, I
think I'm prepared to hold my peace. :-)

Thank you both.

- Isaac

On Thu, Sep 10, 2009 at 1:19 PM, Freeland Abbott  wrote:
> Going forward, I think Ray said incubator bits will either migrate into GWT
> proper (and be maintained and branched for releases there) or will
> "languish," so I imagine the advice will gradually become "don't use
> incubator."  I take "languish" as meaning we'd probably remain stable
> against existing releases, but face bitrot against trunk which might become
> bitrot against new GWT releases, and be fixed only as cases were called out.
>  That's my personal interpretation, though; I don't think we've declared a
> definition.
> Anything that does remain in incubator I think should have release branches,
> as Ray suggests... I think it does help the morass, because you can leave
> behind a stably working incubator against 1.6/1.7/whatever, and only need
> the trunk to work with a trunk of GWT.
> If incubator is relatively quiet, I think that's easier... if it's noisy,
> then you need the incubator's current-GWT-release branch to be noisy also,
> and suck up the merges to incubator trunk, drag on RAD or not.  But I think
> it's just bad news to have a given incubator branch promising to be
> compatible with some plural number of GWT branches, which is where we are
> now I'd rather do merges, and not have to straddle an open-ended set of
> differences between GWT branches.
>
>
> On Thu, Sep 10, 2009 at 1:06 PM, Isaac Truett  wrote:
>>
>> I am confident that r6108 fixed the problem I was having with GWT
>> trunk last night. I think I just happened to try to build during a
>> brief period where the build had broken. By the time r6108 had been
>> committed, I had already moved on to other things.
>>
>> I see what you're saying about incubator being bogged down by
>> backwards compatibility. I had thought of incubator more as a place to
>> develop new APIs rather than a place to build on pre-release APIs. The
>> issue as it sounds to me is that when a new API develops outside of
>> incubator (such as in GWT trunk), you want to develop/update incubator
>> widgets with that API before it gets into a GWT milestone.
>>
>> Would a branch for 1.7 really help with the morass problem? If you
>> maintain the branch, then you still have to code incubator changes
>> against two different versions of GWT. If you don't maintain the
>> branch, then it's not particularly useful.
>>
>> Going forward should the advice be "don't use incubator unless you
>> plan to stay at the bleeding edge of GWT trunk?" I can't speak for
>> other developers, but if that had been the case then I don't think I
>> would've ever used incubator widgets in my work projects. Maybe I
>> shouldn't have used them, but they've been very helpful so far. None
>> of the widgets have been production quality to begin with, but I've
>> been able to report bugs and get bug fixes committed, sometimes
>> supplying fixes myself, and build from incubator trunk without
>> worrying that I'd have to update my GWT core to a trunk build. Losing
>> that assurance will hurt, but it won't be the end of the world. It
>> will definitely make it harder for me to benefit from the latest
>> incubator widget bug fixes.
>>
>>
>>
>>
>>
>> On Thu, Sep 10, 2009 at 11:44 AM, Ray Ryan  wrote:
>> > I built incubator against trunk last night. Are you still seeing trouble
>> > there?
>> > The problem on our end has been that having to maintain code that works
>> > both
>> > with trunk and with the previous release makes it very difficult to
>> > iterate
>> > rapidly on incubator code. What was supposed to be a place that we could
>> > rapidly develop new features instead turns into a morass where forward
>> > progress is twice as hard a normal. That's why UiBinder in particular
>> > never
>> > moved to incubator.
>> > Our expectation is that new features will be either developed directly
>> > in
>> > trunk (e.g. UiBinder), or else in separate projects on code.google.com
>> > that
>> > can determine their own policies on compatibility and contributors (e.g.
>> > Gin). The items that live in incubator already will either gradually
>> > move to
>> > trunk or languish.
>> > It sounds like we need to think a bit harder how to handle the stuff
>> > that
>> > hasn't graduate yet, but which is still in use. My knee jerk is to cut a
>> > 1.7
>> > branch just before the patch that killed off StyleInjector. How does
>> > that
>> > sound?
>> > rjrjr
>> >
>> > On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett  wrote:
>> >>
>> >> [oops - +gwtc]
>> >>
>> >>
>> >> Hi, Ray,
>> >>
>> >> I appreciate the drive to move forward and I applaud jumping on
>> >> opportunities to remove redundant code.
>> >>
>> >> The reason this policy was important, to me at least, is that it
>> >>

[gwt-contrib] Re: GWT Incubator compatibility policy

[Freeland Abbott]

Going forward, I think Ray said incubator bits will either migrate into GWT
proper (and be maintained and branched for releases there) or will
"languish," so I imagine the advice will gradually become "don't use
incubator."  I take "languish" as meaning we'd probably remain stable
against existing releases, but face bitrot against trunk which might become
bitrot against new GWT releases, and be fixed only as cases were called out.
 That's my personal interpretation, though; I don't think we've declared a
definition.
Anything that does remain in incubator I think should have release branches,
as Ray suggests... I think it does help the morass, because you can leave
behind a stably working incubator against 1.6/1.7/whatever, and only need
the trunk to work with a trunk of GWT.

If incubator is relatively quiet, I think that's easier... if it's noisy,
then you need the incubator's current-GWT-release branch to be noisy also,
and suck up the merges to incubator trunk, drag on RAD or not.  But I think
it's just bad news to have a given incubator branch promising to be
compatible with some plural number of GWT branches, which is where we are
now I'd rather do merges, and not have to straddle an open-ended set of
differences between GWT branches.



On Thu, Sep 10, 2009 at 1:06 PM, Isaac Truett  wrote:

>
> I am confident that r6108 fixed the problem I was having with GWT
> trunk last night. I think I just happened to try to build during a
> brief period where the build had broken. By the time r6108 had been
> committed, I had already moved on to other things.
>
> I see what you're saying about incubator being bogged down by
> backwards compatibility. I had thought of incubator more as a place to
> develop new APIs rather than a place to build on pre-release APIs. The
> issue as it sounds to me is that when a new API develops outside of
> incubator (such as in GWT trunk), you want to develop/update incubator
> widgets with that API before it gets into a GWT milestone.
>
> Would a branch for 1.7 really help with the morass problem? If you
> maintain the branch, then you still have to code incubator changes
> against two different versions of GWT. If you don't maintain the
> branch, then it's not particularly useful.
>
> Going forward should the advice be "don't use incubator unless you
> plan to stay at the bleeding edge of GWT trunk?" I can't speak for
> other developers, but if that had been the case then I don't think I
> would've ever used incubator widgets in my work projects. Maybe I
> shouldn't have used them, but they've been very helpful so far. None
> of the widgets have been production quality to begin with, but I've
> been able to report bugs and get bug fixes committed, sometimes
> supplying fixes myself, and build from incubator trunk without
> worrying that I'd have to update my GWT core to a trunk build. Losing
> that assurance will hurt, but it won't be the end of the world. It
> will definitely make it harder for me to benefit from the latest
> incubator widget bug fixes.
>
>
>
>
>
> On Thu, Sep 10, 2009 at 11:44 AM, Ray Ryan  wrote:
> > I built incubator against trunk last night. Are you still seeing trouble
> > there?
> > The problem on our end has been that having to maintain code that works
> both
> > with trunk and with the previous release makes it very difficult to
> iterate
> > rapidly on incubator code. What was supposed to be a place that we could
> > rapidly develop new features instead turns into a morass where forward
> > progress is twice as hard a normal. That's why UiBinder in particular
> never
> > moved to incubator.
> > Our expectation is that new features will be either developed directly in
> > trunk (e.g. UiBinder), or else in separate projects on code.google.comthat
> > can determine their own policies on compatibility and contributors (e.g.
> > Gin). The items that live in incubator already will either gradually move
> to
> > trunk or languish.
> > It sounds like we need to think a bit harder how to handle the stuff that
> > hasn't graduate yet, but which is still in use. My knee jerk is to cut a
> 1.7
> > branch just before the patch that killed off StyleInjector. How does that
> > sound?
> > rjrjr
> >
> > On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett  wrote:
> >>
> >> [oops - +gwtc]
> >>
> >>
> >> Hi, Ray,
> >>
> >> I appreciate the drive to move forward and I applaud jumping on
> >> opportunities to remove redundant code.
> >>
> >> The reason this policy was important, to me at least, is that it
> >> provided a baseline to work against. The code in the incubator can be
> >> very useful (I use PagingScrollTable extensively and used DatePicker
> >> from incubator before it graduated) but it's also risky because the
> >> code is still experimental and subject to change. The assurance that
> >> those changes would be compatible with a packaged and released GWT
> >> build (even just a milestone) meant that I could build incubator from
> >> trunk and pick up the latest fe

[gwt-contrib] Re: GWT Incubator compatibility policy

[Isaac Truett]

I am confident that r6108 fixed the problem I was having with GWT
trunk last night. I think I just happened to try to build during a
brief period where the build had broken. By the time r6108 had been
committed, I had already moved on to other things.

I see what you're saying about incubator being bogged down by
backwards compatibility. I had thought of incubator more as a place to
develop new APIs rather than a place to build on pre-release APIs. The
issue as it sounds to me is that when a new API develops outside of
incubator (such as in GWT trunk), you want to develop/update incubator
widgets with that API before it gets into a GWT milestone.

Would a branch for 1.7 really help with the morass problem? If you
maintain the branch, then you still have to code incubator changes
against two different versions of GWT. If you don't maintain the
branch, then it's not particularly useful.

Going forward should the advice be "don't use incubator unless you
plan to stay at the bleeding edge of GWT trunk?" I can't speak for
other developers, but if that had been the case then I don't think I
would've ever used incubator widgets in my work projects. Maybe I
shouldn't have used them, but they've been very helpful so far. None
of the widgets have been production quality to begin with, but I've
been able to report bugs and get bug fixes committed, sometimes
supplying fixes myself, and build from incubator trunk without
worrying that I'd have to update my GWT core to a trunk build. Losing
that assurance will hurt, but it won't be the end of the world. It
will definitely make it harder for me to benefit from the latest
incubator widget bug fixes.





On Thu, Sep 10, 2009 at 11:44 AM, Ray Ryan  wrote:
> I built incubator against trunk last night. Are you still seeing trouble
> there?
> The problem on our end has been that having to maintain code that works both
> with trunk and with the previous release makes it very difficult to iterate
> rapidly on incubator code. What was supposed to be a place that we could
> rapidly develop new features instead turns into a morass where forward
> progress is twice as hard a normal. That's why UiBinder in particular never
> moved to incubator.
> Our expectation is that new features will be either developed directly in
> trunk (e.g. UiBinder), or else in separate projects on code.google.com that
> can determine their own policies on compatibility and contributors (e.g.
> Gin). The items that live in incubator already will either gradually move to
> trunk or languish.
> It sounds like we need to think a bit harder how to handle the stuff that
> hasn't graduate yet, but which is still in use. My knee jerk is to cut a 1.7
> branch just before the patch that killed off StyleInjector. How does that
> sound?
> rjrjr
>
> On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett  wrote:
>>
>> [oops - +gwtc]
>>
>>
>> Hi, Ray,
>>
>> I appreciate the drive to move forward and I applaud jumping on
>> opportunities to remove redundant code.
>>
>> The reason this policy was important, to me at least, is that it
>> provided a baseline to work against. The code in the incubator can be
>> very useful (I use PagingScrollTable extensively and used DatePicker
>> from incubator before it graduated) but it's also risky because the
>> code is still experimental and subject to change. The assurance that
>> those changes would be compatible with a packaged and released GWT
>> build (even just a milestone) meant that I could build incubator from
>> trunk and pick up the latest features and bugfixes as long as my
>> project tracked the latest GWT build. Because of the GWT policies on
>> deprecation and backwards compatibility, this has been fairly easy in
>> practice. As it stands now, incubator will not compile except against
>> GWT trunk, which is also notoriously unstable (it wasn't building as
>> recently as last night, which I see was corrected this morning). This
>> presents a much higher risk for those of us using incubator code.
>>
>> It also becomes harder to work on the incubator itself when it has to
>> compile against GWT trunk. I wanted to look into issue #267 last night
>> and I was stymied by GWT trunk not being in a buildable state. Not an
>> insurmountable obstacle, but one that seems unnecessary to me.
>>
>> - Isaac
>>
>>
>> On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
>> > Hey, Isaac.
>> > That policy has proven very difficult to live with. (And to tell you the
>> > truth I forgot about it.)
>> > The reasoning here was that we have released incubator jars that work
>> > with
>> > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it
>> > prove
>> > necessary to go back and do so we can go back and branch.
>> > In the meantime, we were faced bugs due to FastTree in particular being
>> > tied
>> > to the old StyleInjector while new development was moving to the version
>> > in
>> > GWT.  We saw the opportunity to delete redundant code and took it.
>> > Is this going to cause probl

[gwt-contrib] Re: GWT Incubator compatibility policy

[jay]

So...as of right now, what is the *last* version of gwt-incubator that
is guaranteed to work with GWT 1.7? Is it safe to assume that it is
the version immediately prior to the removal of StyleInjector?

thanks,

jay

On Sep 10, 8:28 am, Isaac Truett  wrote:
> [oops - +gwtc]
>
> Hi, Ray,
>
> I appreciate the drive to move forward and I applaud jumping on
> opportunities to remove redundant code.
>
> The reason this policy was important, to me at least, is that it
> provided a baseline to work against. The code in the incubator can be
> very useful (I use PagingScrollTable extensively and used DatePicker
> from incubator before it graduated) but it's also risky because the
> code is still experimental and subject to change. The assurance that
> those changes would be compatible with a packaged and released GWT
> build (even just a milestone) meant that I could build incubator from
> trunk and pick up the latest features and bugfixes as long as my
> project tracked the latest GWT build. Because of the GWT policies on
> deprecation and backwards compatibility, this has been fairly easy in
> practice. As it stands now, incubator will not compile except against
> GWT trunk, which is also notoriously unstable (it wasn't building as
> recently as last night, which I see was corrected this morning). This
> presents a much higher risk for those of us using incubator code.
>
> It also becomes harder to work on the incubator itself when it has to
> compile against GWT trunk. I wanted to look into issue #267 last night
> and I was stymied by GWT trunk not being in a buildable state. Not an
> insurmountable obstacle, but one that seems unnecessary to me.
>
> - Isaac
>
>
>
> On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
> > Hey, Isaac.
> > That policy has proven very difficult to live with. (And to tell you the
> > truth I forgot about it.)
> > The reasoning here was that we have released incubator jars that work with
> > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it prove
> > necessary to go back and do so we can go back and branch.
> > In the meantime, we were faced bugs due to FastTree in particular being tied
> > to the old StyleInjector while new development was moving to the version in
> > GWT.  We saw the opportunity to delete redundant code and took it.
> > Is this going to cause problems for anyone?
> > rjrjr
>
> > On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett  wrote:
>
> >> Last year, Emily stated that it would compile against the "latest
> >> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
> >> I've seen, so under the policy from last year StyleInjector should not
> >> have been removed in revisions 1712-1715.
>
> >> So, what's the current policy for incubator trunk compatibility?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT Incubator compatibility policy

[Ray Ryan]

I built incubator against trunk last night. Are you still seeing trouble
there?
The problem on our end has been that having to maintain code that works both
with trunk and with the previous release makes it very difficult to iterate
rapidly on incubator code. What was supposed to be a place that we could
rapidly develop new features instead turns into a morass where forward
progress is twice as hard a normal. That's why UiBinder in particular never
moved to incubator.

Our expectation is that new features will be either developed directly in
trunk (e.g. UiBinder), or else in separate projects on code.google.com that
can determine their own policies on compatibility and contributors (e.g.
Gin). The items that live in incubator already will either gradually move to
trunk or languish.

It sounds like we need to think a bit harder how to handle the stuff that
hasn't graduate yet, but which is still in use. My knee jerk is to cut a 1.7
branch just before the patch that killed off StyleInjector. How does that
sound?

rjrjr

On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett  wrote:

>
> [oops - +gwtc]
>
>
> Hi, Ray,
>
> I appreciate the drive to move forward and I applaud jumping on
> opportunities to remove redundant code.
>
> The reason this policy was important, to me at least, is that it
> provided a baseline to work against. The code in the incubator can be
> very useful (I use PagingScrollTable extensively and used DatePicker
> from incubator before it graduated) but it's also risky because the
> code is still experimental and subject to change. The assurance that
> those changes would be compatible with a packaged and released GWT
> build (even just a milestone) meant that I could build incubator from
> trunk and pick up the latest features and bugfixes as long as my
> project tracked the latest GWT build. Because of the GWT policies on
> deprecation and backwards compatibility, this has been fairly easy in
> practice. As it stands now, incubator will not compile except against
> GWT trunk, which is also notoriously unstable (it wasn't building as
> recently as last night, which I see was corrected this morning). This
> presents a much higher risk for those of us using incubator code.
>
> It also becomes harder to work on the incubator itself when it has to
> compile against GWT trunk. I wanted to look into issue #267 last night
> and I was stymied by GWT trunk not being in a buildable state. Not an
> insurmountable obstacle, but one that seems unnecessary to me.
>
> - Isaac
>
>
> On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
> > Hey, Isaac.
> > That policy has proven very difficult to live with. (And to tell you the
> > truth I forgot about it.)
> > The reasoning here was that we have released incubator jars that work
> with
> > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it
> prove
> > necessary to go back and do so we can go back and branch.
> > In the meantime, we were faced bugs due to FastTree in particular being
> tied
> > to the old StyleInjector while new development was moving to the version
> in
> > GWT.  We saw the opportunity to delete redundant code and took it.
> > Is this going to cause problems for anyone?
> > rjrjr
> >
> > On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett  wrote:
> >>
> >> Last year, Emily stated that it would compile against the "latest
> >> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
> >> I've seen, so under the policy from last year StyleInjector should not
> >> have been removed in revisions 1712-1715.
> >>
> >> So, what's the current policy for incubator trunk compatibility?
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add permutation info to index page for each permutation

[spoon]

LGTM

http://gwt-code-reviews.appspot.com/64808

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Fixes double escaping bug in UiBinder messages

[spoon]

LGTM.  One bit of comment cruft would be good to delete.


http://gwt-code-reviews.appspot.com/64810/diff/1/5
File
user/src/com/google/gwt/uibinder/rebind/messages/PlaceholderInterpreter.java
(right):

http://gwt-code-reviews.appspot.com/64810/diff/1/5#newcode115
Line 115: * @return
Auto-generated cruft.

http://gwt-code-reviews.appspot.com/64810/diff/1/8
File user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
(right):

http://gwt-code-reviews.appspot.com/64810/diff/1/8#newcode177
Line 177: assertEquals("funny characters \" \" ' ' & < > > { }", t);
Excellent.

http://gwt-code-reviews.appspot.com/64810

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] GWT Incubator compatibility policy

[Isaac Truett]

[oops - +gwtc]


Hi, Ray,

I appreciate the drive to move forward and I applaud jumping on
opportunities to remove redundant code.

The reason this policy was important, to me at least, is that it
provided a baseline to work against. The code in the incubator can be
very useful (I use PagingScrollTable extensively and used DatePicker
from incubator before it graduated) but it's also risky because the
code is still experimental and subject to change. The assurance that
those changes would be compatible with a packaged and released GWT
build (even just a milestone) meant that I could build incubator from
trunk and pick up the latest features and bugfixes as long as my
project tracked the latest GWT build. Because of the GWT policies on
deprecation and backwards compatibility, this has been fairly easy in
practice. As it stands now, incubator will not compile except against
GWT trunk, which is also notoriously unstable (it wasn't building as
recently as last night, which I see was corrected this morning). This
presents a much higher risk for those of us using incubator code.

It also becomes harder to work on the incubator itself when it has to
compile against GWT trunk. I wanted to look into issue #267 last night
and I was stymied by GWT trunk not being in a buildable state. Not an
insurmountable obstacle, but one that seems unnecessary to me.

- Isaac


On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
> Hey, Isaac.
> That policy has proven very difficult to live with. (And to tell you the
> truth I forgot about it.)
> The reasoning here was that we have released incubator jars that work with
> 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it prove
> necessary to go back and do so we can go back and branch.
> In the meantime, we were faced bugs due to FastTree in particular being tied
> to the old StyleInjector while new development was moving to the version in
> GWT.  We saw the opportunity to delete redundant code and took it.
> Is this going to cause problems for anyone?
> rjrjr
>
> On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett  wrote:
>>
>> Last year, Emily stated that it would compile against the "latest
>> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
>> I've seen, so under the policy from last year StyleInjector should not
>> have been removed in revisions 1712-1715.
>>
>> So, what's the current policy for incubator trunk compatibility?
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT Incubator compatibility policy

[Ray Ryan]

Hey, Isaac.
That policy has proven very difficult to live with. (And to tell you the
truth I forgot about it.)

The reasoning here was that we have released incubator jars that work with
1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it prove
necessary to go back and do so we can go back and branch.

In the meantime, we were faced bugs due to FastTree in particular being tied
to the old StyleInjector while new development was moving to the version in
GWT.  We saw the opportunity to delete redundant code and took it.

Is this going to cause problems for anyone?

rjrjr

On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett  wrote:

> Last year, Emily stated that it would compile against the "latest
> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
> I've seen, so under the policy from last year StyleInjector should not
> have been removed in revisions 1712-1715.
>
> So, what's the current policy for incubator trunk compatibility?
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6111 committed - Add additional icon sizes for Chrome extension.

[codesite-noreply]

Revision: 6111
Author: j...@google.com
Date: Thu Sep 10 07:24:58 2009
Log: Add additional icon sizes for Chrome extension.

http://code.google.com/p/google-web-toolkit/source/detail?r=6111

Added:
  /trunk/plugins/npapi/prebuilt/gwt128.png
  /trunk/plugins/npapi/prebuilt/gwt16.png
  /trunk/plugins/npapi/prebuilt/gwt64.png
Modified:
  /trunk/plugins/npapi/prebuilt/gwt32.png
  /trunk/plugins/npapi/prebuilt/manifest.json

===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwt128.pngThu Sep 10 07:24:58 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwt16.png Thu Sep 10 07:24:58 2009
Binary file, no diff available.
===
--- /dev/null   
+++ /trunk/plugins/npapi/prebuilt/gwt64.png Thu Sep 10 07:24:58 2009
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/gwt32.png Wed Sep  9 15:45:43 2009
+++ /trunk/plugins/npapi/prebuilt/gwt32.png Thu Sep 10 07:24:58 2009
Binary file, no diff available.
===
--- /trunk/plugins/npapi/prebuilt/manifest.json Wed Sep  9 15:45:43 2009
+++ /trunk/plugins/npapi/prebuilt/manifest.json Thu Sep 10 07:24:58 2009
@@ -3,7 +3,10 @@
"version": "0.9.0",
"description": "A plugin to enable debugging with GWT's Development  
Mode",
"icons": {
-"32": "gwt32.png"
+"16": "gwt16.png",
+"32": "gwt32.png",
+"64": "gwt64.png",
+"128": "gwt128.png"
},
"plugins": [
  { "path": "winnt_x86-msvc/npOOPHM.dll", "public": true }

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: IsSerializable in 2.0 : deprecate ?

[Nathan Wells]

Thanks Ray, that's comforting to hear, after having built an application on
the assumption that IsSerializable is a recommended way to do gwt-rpc. Not
that it would be a huge problem... just probably a day of refactoring and
adding @SupressWarning annotations.

Thanks again :)
Nathan Wells


On Thu, Sep 10, 2009 at 7:21 AM, John Tamplin  wrote:

> On Thu, Sep 10, 2009 at 2:11 AM, George Georgovassilis <
> g.georgovassi...@gmail.com
> > wrote:
>
>> I was under the impression that IsSerializable had been deprecated de
>> facto. John, does IsSerializable currently override the serialization
>> policy or this this a proposed behavior?
>>
>
> It doesn't override it -- the legacy serialization policy, which is what is
> used if no *.gwt.rpc file is found, allows anything marked IsSerializable to
> be serialized.  Allowing Serializable is a security risk in this case, since
> many classes are marked as Serializable that should not be returned, and
> simply instantiating one of them might provide an attack vector if a
> malicious client knew it was on the server's classpath.
>
> IsSerializable doesn't have this problem because it is only used for GWT,
> so if the developer marked it in such a way they are explicitly saying it is
> ok for GWT to serialize.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: IsSerializable in 2.0 : deprecate ?

[John Tamplin]

On Thu, Sep 10, 2009 at 2:11 AM, George Georgovassilis <
g.georgovassi...@gmail.com> wrote:

> I was under the impression that IsSerializable had been deprecated de
> facto. John, does IsSerializable currently override the serialization
> policy or this this a proposed behavior?
>

It doesn't override it -- the legacy serialization policy, which is what is
used if no *.gwt.rpc file is found, allows anything marked IsSerializable to
be serialized.  Allowing Serializable is a security risk in this case, since
many classes are marked as Serializable that should not be returned, and
simply instantiating one of them might provide an attack vector if a
malicious client knew it was on the server's classpath.

IsSerializable doesn't have this problem because it is only used for GWT, so
if the developer marked it in such a way they are explicitly saying it is ok
for GWT to serialize.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: IsSerializable in 2.0 : deprecate ?

[Ray Ryan]

The conclusion here is *not* to deprecate it.

On Thursday, September 10, 2009, Nathan Wells  wrote:
>
> Could someone please update the article at
>
> http://code.google.com/webtoolkit/doc/1.6/FAQ_Server.html#Does_the_GWT_RPC_system_support_the_use_of_java.io.Serializable
>
> to indicate that IsSerializable is deprecated (or de facto deprecated,
> or will be deprecated, or whatever)? When I read this article it
> seemed like GWT was encouraging the use of IsSerializable over
> Serializable.
>
> Is this something I should file a ticket on?
>
> On Sep 10, 12:46 am, nicolas de loof  wrote:
>> I understand the idea about some classes beeing GWT-serializable and not
>> Java-serializable but really can't find a valid use case. Seems more a
>> misconception to me - just my humble opinion ;)
>>
>> 2009/9/10 George Georgovassilis 
>>
>>
>>
>>
>>
>> > I was under the impression that IsSerializable had been deprecated de
>> > facto. John, does IsSerializable currently override the serialization
>> > policy or this this a proposed behavior?
>>
>> > On Sep 9, 4:27 pm, John Tamplin  wrote:
>> > > On Wed, Sep 9, 2009 at 9:06 AM, nicolas de loof <
>> > nicolas.del...@gmail.com>wrote:
>>
>> > > > I wonder that IsSerializable is still in trunk without a depreaction
>> > > > annotation. java.io.Serializable is supported by GWT-RPC since few
>> > major
>> > > > versions, maybe it's time to remove such legacy marker interface.
>>
>> > > I don't know if this is sufficient reason to keep it, but two reasons:
>>
>> > >    - you might want a class to be serializable only in GWT and not in
>> > normal
>> > >    Java
>> > >    - IsSerializable means that it is always serializable, even without a
>> > >    serialization policy file on the server.  I think there are better
>> > ways to
>> > >    do this sort of thing, but some people may be depending on this
>> > >    functionality
>>
>> > > Maybe it could also extends Serializable so that it can be easier to
>> > switch
>>
>> > > > the related tools.
>>
>> > > Other than the first issue above, sounds like a good idea.
>>
>> > > --
>> > > John A. Tamplin
>> > > Software Engineer (GWT), Google
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Initial implementations of Stack and Split layout panels, along with a few checkstyle tweaks.

[Bruce Johnson]

yay

On Thu, Sep 10, 2009 at 8:48 AM,  wrote:

>
> On 2009/09/04 22:37:44, Ray Ryan wrote:
> > LGTM
>
> Committed @r6110.
>
> http://gwt-code-reviews.appspot.com/65804
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Initial implementations of Stack and Split layout panels, along with a few checkstyle tweaks.

[jgw]

On 2009/09/04 22:37:44, Ray Ryan wrote:
> LGTM

Committed @r6110.

http://gwt-code-reviews.appspot.com/65804

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] r6110 committed - Initial implementations of Stack and Split layout panels, along with a...

[codesite-noreply]

Revision: 6110
Author: j...@google.com
Date: Thu Sep 10 05:47:55 2009
Log: Initial implementations of Stack and Split layout panels, along with a  
few
checkstyle tweaks.
Review: http://gwt-code-reviews.appspot.com/65804
http://code.google.com/p/google-web-toolkit/source/detail?r=6110

Added:
  /trunk/user/javadoc/com/google/gwt/examples/SplitLayoutPanelExample.java
  /trunk/user/javadoc/com/google/gwt/examples/StackLayoutPanelExample.java
  /trunk/user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java
  /trunk/user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java
Modified:
  /trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java

===
--- /dev/null
+++  
/trunk/user/javadoc/com/google/gwt/examples/SplitLayoutPanelExample.java
 
Thu Sep 10 05:47:55 2009
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may  
not
+ * use this file except in compliance with the License. You may obtain a  
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,  
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations  
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.user.client.ui.HTML;
+import com.google.gwt.user.client.ui.RootLayoutPanel;
+import com.google.gwt.user.client.ui.SplitLayoutPanel;
+import com.google.gwt.user.client.ui.DockLayoutPanel.Direction;
+
+public class SplitLayoutPanelExample implements EntryPoint {
+
+  public void onModuleLoad() {
+// Create a three-pane layout with splitters.
+SplitLayoutPanel p = new SplitLayoutPanel();
+p.add(new HTML("navigation"), Direction.WEST, 128);
+p.add(new HTML("list"), Direction.NORTH, 384);
+p.add(new HTML("details"), Direction.CENTER, 0);
+
+// Note the explicit call to layout(). This is required for the layout  
to
+// take effect.
+p.layout();
+
+// Attach the LayoutPanel to the RootLayoutPanel. The latter will  
listen for
+// resize events on the window to ensure that its children are  
informed of
+// possible size changes.
+RootLayoutPanel rp = RootLayoutPanel.get();
+rp.add(p);
+
+// The RootLayoutPanel also requires that its layout() method be  
explicitly
+// called for the initial layout to take effect.
+rp.layout();
+  }
+}
===
--- /dev/null
+++  
/trunk/user/javadoc/com/google/gwt/examples/StackLayoutPanelExample.java
 
Thu Sep 10 05:47:55 2009
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may  
not
+ * use this file except in compliance with the License. You may obtain a  
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,  
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations  
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.dom.client.Style.Unit;
+import com.google.gwt.user.client.ui.HTML;
+import com.google.gwt.user.client.ui.RootLayoutPanel;
+import com.google.gwt.user.client.ui.StackLayoutPanel;
+
+public class StackLayoutPanelExample implements EntryPoint {
+
+  public void onModuleLoad() {
+// Create a three-item stack, with headers sized in EMs.
+StackLayoutPanel p = new StackLayoutPanel(Unit.EM);
+p.add(new HTML("this"), new HTML("[this]"), 128);
+p.add(new HTML("that"), new HTML("[that]"), 384);
+p.add(new HTML("the other"), new HTML("[the other]"), 0);
+
+// Note the explicit call to layout(). This is required for the layout  
to
+// take effect.
+p.layout();
+
+// Attach the LayoutPanel to the RootLayoutPanel. The latter will  
listen for
+// resize events on the window to ensure that its children are  
informed of
+// possible size changes.
+RootLayoutPanel rp = RootLayoutPanel.get();
+rp.add(p);
+
+// The RootLayoutPanel also requires that its layout() method be  
explicitly
+// called for the initial layout to take effect.
+rp.layout();
+  }
+}
===
--- /dev/null
+++ /trunk/user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java Thu  
Sep 10 05:47:55 2009
@@ -0,0 +1,294 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may  
not
+ * u

[gwt-contrib] Re: IsSerializable in 2.0 : deprecate ?

[Nathan Wells]

Could someone please update the article at

http://code.google.com/webtoolkit/doc/1.6/FAQ_Server.html#Does_the_GWT_RPC_system_support_the_use_of_java.io.Serializable

to indicate that IsSerializable is deprecated (or de facto deprecated,
or will be deprecated, or whatever)? When I read this article it
seemed like GWT was encouraging the use of IsSerializable over
Serializable.

Is this something I should file a ticket on?

On Sep 10, 12:46 am, nicolas de loof  wrote:
> I understand the idea about some classes beeing GWT-serializable and not
> Java-serializable but really can't find a valid use case. Seems more a
> misconception to me - just my humble opinion ;)
>
> 2009/9/10 George Georgovassilis 
>
>
>
>
>
> > I was under the impression that IsSerializable had been deprecated de
> > facto. John, does IsSerializable currently override the serialization
> > policy or this this a proposed behavior?
>
> > On Sep 9, 4:27 pm, John Tamplin  wrote:
> > > On Wed, Sep 9, 2009 at 9:06 AM, nicolas de loof <
> > nicolas.del...@gmail.com>wrote:
>
> > > > I wonder that IsSerializable is still in trunk without a depreaction
> > > > annotation. java.io.Serializable is supported by GWT-RPC since few
> > major
> > > > versions, maybe it's time to remove such legacy marker interface.
>
> > > I don't know if this is sufficient reason to keep it, but two reasons:
>
> > >    - you might want a class to be serializable only in GWT and not in
> > normal
> > >    Java
> > >    - IsSerializable means that it is always serializable, even without a
> > >    serialization policy file on the server.  I think there are better
> > ways to
> > >    do this sort of thing, but some people may be depending on this
> > >    functionality
>
> > > Maybe it could also extends Serializable so that it can be easier to
> > switch
>
> > > > the related tools.
>
> > > Other than the first issue above, sounds like a good idea.
>
> > > --
> > > John A. Tamplin
> > > Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---