[gwt-contrib] Can't get 'ant test' to pass it times out
Hi All, I am trying to contribute NoSuchFieldError (and it's parent classes) to GWT. I have not been able to get get the 'ant test' target to work, my most recent attempt is getting a timeout after 5 hours :( BUILD FAILED /home/scott/gwt-src/trunk/build.xml:162: The following error occurred while executing this line:/home/scott/gwt-src/trunk/build.xml:27: The following error occurred while executing this line:/home/scott/gwt-src/trunk/build.xml:71: The following error occurred while executing this line:/home/scott/gwt-src/trunk/user/build.xml:471: Interrupted task parallel. Waited 5 hour, but this task did not complete. Total time: 331 minutes 11 seconds Any idea what I am doing wrong, or how to fix it? This is a copy of; http://code.google.com/p/google-web-toolkit/issues/detail?id=8931q=adligo.comcolspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars I was having issues posting to this group. Cheers, Scott -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0f9795eb-4318-4397-9927-bbe29add7e39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later removing the old one. Any library/project compatible with N is then compatible with N+1 in as many cases as possible. If we like b), I'd leave any static DOM methods, but dig in further and hit any overridable methods. If a) is preferred, we can just cut to the chase and remove user.client.Element entirely today. If we did things right in 2.6 (and I have no reason to think otherwise), user code (anything not from GWT proper, including applications and downstream libraries) can be written without any reference to user.client.Element, using dom.client.Element exclusively and never calling any deprecated method (related to Element). So after a grace period where downstream libraries use the same technique that GWT used in 2.6 to have both Element coexist and allow users to move entirely to dom.client.Element, I'm in favor of just removing user.client.Element. The question is how long that grace period should be. Whichever the deprecation policy we'll settle on (hopefully at the next SC meeting), I wouldn't oppose using a longer period for that specific case given how big a change it is. Note: for those libraries that still have to deal with user.element.Element for backwards compatibility; maybe we could remove all uses of user.client.Element in GWT but leave the class there (or move it to a gwt-user-compat.jar). Libraries could then continue to use user.client.Element for a while provided they make sure to cast all possible uses of dom.element.Element in GWT proper to user.client.Element. Or maybe I'm just wrong and it wouldn't work ;-) -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/74b4f066-a75a-4362-8c70-56e09ddf4b42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7 release plan
Hi Daniel, this issue ( https://code.google.com/p/google-web-toolkit/issues/detail?id=8938) should be included in GWT 2.7. Best Michael Am Mittwoch, 1. Oktober 2014 21:15:26 UTC+2 schrieb Daniel Kurka: Hi all, we just settled on a GWT 2.7 release plan: - We *code freeze* on *October 7th* and branch for GWT 2.7. - As soon as we have the *remaining patches submitted*, we put out a beta1 build, this should be no later than *October 7th.* - Putting out a *beta1 externally* allows us to collect feedback on the new super dev mode integration externally as well. - We are going to *flip incremental to default* tomorrow and *wait for 1-2 weeks* for google internal feedback, if there is no serious issues we are going to *put out RC1* - GWT 2.7 will still be compatible with Java 6. Patches / Fixes that need to go in: - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ (dankurka) - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka). - Investigate why some people are seeing errors with incremental not restricting to one permutation (dankurka). - Public directories are not copied o the war directory when using SDM (skybrian). - Restore Java 6 compatibility (skybrian). - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse) Patches that are nice to have: - Improve exception logging in SDM (goktug). *If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.* -Daniel -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cbc5c317-d21e-484c-bb99-e0274a346d69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Can't get 'ant test' to pass it times out
Hmm instead of ant I mostly use Eclipse to run tests. To do so I enable the GPE plugin for gwt-user/gwt-dev projects in Eclipse and then run tests as usual. Since GPE picks up the GWT source project as SDK it works quite well for me. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0916bc14-d1f7-4b9a-be89-f0e2ffb56369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Can't get 'ant test' to pass it times out
Just for your information, I was writing a document explaining how to run tests from command line, I have taken advantage of this thread to commit a first version to gerrit, feel free to play with the examples and make suggestions. https://gwt-review.googlesource.com/#/c/9552/ On Wed, Oct 8, 2014 at 12:40 PM, Jens jens.nehlme...@gmail.com wrote: Hmm instead of ant I mostly use Eclipse to run tests. To do so I enable the GPE plugin for gwt-user/gwt-dev projects in Eclipse and then run tests as usual. Since GPE picks up the GWT source project as SDK it works quite well for me. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0916bc14-d1f7-4b9a-be89-f0e2ffb56369%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/0916bc14-d1f7-4b9a-be89-f0e2ffb56369%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvL4vkAc1iG7_9Yo29qtwftCdHuc8y51bCJxnCz6m0gBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7 release plan
Hi, thank you all for your hard work. We have been using GWT and SDM with great success in a big financial software company :). There is one major feature that is still not merged : NavigableMap https://gwt-review.googlesource.com/#/c/3650/ Will it be possible to have it in the 2.7 realease ? Thanks Le mercredi 1 octobre 2014 21:15:26 UTC+2, Daniel Kurka a écrit : Hi all, we just settled on a GWT 2.7 release plan: - We *code freeze* on *October 7th* and branch for GWT 2.7. - As soon as we have the *remaining patches submitted*, we put out a beta1 build, this should be no later than *October 7th.* - Putting out a *beta1 externally* allows us to collect feedback on the new super dev mode integration externally as well. - We are going to *flip incremental to default* tomorrow and *wait for 1-2 weeks* for google internal feedback, if there is no serious issues we are going to *put out RC1* - GWT 2.7 will still be compatible with Java 6. Patches / Fixes that need to go in: - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ (dankurka) - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka). - Investigate why some people are seeing errors with incremental not restricting to one permutation (dankurka). - Public directories are not copied o the war directory when using SDM (skybrian). - Restore Java 6 compatibility (skybrian). - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse) Patches that are nice to have: - Improve exception logging in SDM (goktug). *If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.* -Daniel -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4e282093-c7f0-4b93-b802-d10002fe8af9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. To pick a case at random (ahem, GXT), say you want to override UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't change that return type, since you can't override methods and return a superclass (or a subclass of the superclass). If we assume that no downstream code ever subclasses and overrides any method that returns user.client.Element, yes, we can cut over cleanly in the future, you are right. But GXT notwithstanding, the SimplePanel class is meant to be subclassed and have getContainerElement() return a different container for the child - I'd be very surprised if there is no downstream code that does this somewhere. Example: FooLib v1 is compatible with GWT 2.5, when user.client.Element was not deprecated. It has a SimplePanel subclass called HeaderPanel, which overrides getContainerElement() to return a specific child element. GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with both GWT 2.5 and 2.6. As it should be. To catch up, FooLib v2 would like to remove usages of user.client.Element, but since SimplePanel.getContainerElement() still requires that return type, it can't. The best they can do is find all cases of user.client.Element and cast up to dom.client.Element from the return value of methods like getElement() and getContainerElement(). Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 was writing the cleanest possible code (returning a deprecated type). Not ideal. Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now has SimplePanel.getContainerElement return a supertype of user.client.Element, so subclasses are free to *further restrict* the return type (like v1/v2 is doing), or use the dom.client.Element. The v1 version will probably have issues if it uses the returned value from getContainerElement() as a user.client.Element, but v2 corrected that, so v2 now is compatible with GWT 2.6 and GWT 2.7. Win. Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and since v2 didn't use it any more, in this regard v2 is also compatible with GWT 2.8/3.0. Of course, this won't happen, some other API detail will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required resource tags causing warnings, etc). On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later removing the old one. Any library/project compatible with N is then compatible with N+1 in as many cases as possible. If we like b), I'd leave any static DOM methods, but dig in further and hit any overridable methods. If a) is preferred, we can just cut to the chase and remove user.client.Element entirely today. If we did things right in 2.6 (and I have no reason to think otherwise), user code (anything not from GWT proper, including applications and downstream libraries) can be written without any reference to user.client.Element, using dom.client.Element exclusively and never calling any deprecated method (related to Element). So after a grace period where downstream libraries use the same technique that GWT used
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
@Ray Cromwell will the @Entry annotation for JSInterop be included in GWT
2.7? I think this is essential to handle errors raised by JavaScript.
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
javascript: wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String event,
com.workingflows.js.jscore.client.api.Function?,? fn);
void attr(String attr, Object value);
}
Now suppose that there is an element called SwitchElement, the item is a
JQueryElement but has a particual implementation of a method, for
example:
public class SwitchElement extends JavaScriptObject {
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
The problem is, if the JQueryElement interface is implemented, all
methods
must be implemented. In fact, the implementation of JQueryElement is
performed by the compiler, and I have no access to that implentación.
1) The solution can be: define an Java8 interface with methods
implemented
by default?
2) It is possible to access a Prototype implementation of JQueryElement,
by
example:
public class SwitchElement extends JQueryElement.Prototype{
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
But for this, it is necessary to use APT or the JsType generation
process,
is performed by APT.
I'm right, or very far from reality.
:)
El sábado, 4 de octubre de 2014 15:24:19 UTC-3, Ray Cromwell escribió:
Yes, but it will require Java8, which allows interfaces to contain
static methods. Here's how you'll do it soon when the Java8 stuff
lands:
@JsType
public interface ImageUtils {
public static Texture loadTexture(String url) { return
js($wnd.THREE.ImageUtils.loadTexture($0), url); }
}
ImageUtils.loadTexture(url);
On Sat, Oct 4, 2014 at 8:18 AM, confile michael@googlemail.com
wrote:
Consider the following static JavaScript function:
THREE.ImageUtils = {
loadTexture: function (url) { ... }
}
The way I use to create the static function with JsInterop is to
create
an
interface for ImageUtils and then create an inner abstract class
MyStatic
which contains the static methods implemented with JSNI.
Here is an example of the above class:
@JsType
public interface ImageUtils {
public static abstract class MyStatic {
public static native Texture create(String url) /*-{
return new $wnd.THREE.ImageUtils.loadTexture(url);
}-*/;
}
}
I don't think this is the best solution. Is there a better way to
handle
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
We are not really making a release for JsInterop for 2.7 and it is not
meant to be used in production and missing a lot of stuff.
The released stuff is just something that people can play with and give
some feedback.
On Wed, Oct 8, 2014 at 10:31 AM, confile michael.gorsk...@googlemail.com
wrote:
@Ray Cromwell will the @Entry annotation for JSInterop be included in GWT
2.7? I think this is essential to handle errors raised by JavaScript.
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String event,
com.workingflows.js.jscore.client.api.Function?,? fn);
void attr(String attr, Object value);
}
Now suppose that there is an element called SwitchElement, the item is
a
JQueryElement but has a particual implementation of a method, for
example:
public class SwitchElement extends JavaScriptObject {
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
The problem is, if the JQueryElement interface is implemented, all
methods
must be implemented. In fact, the implementation of JQueryElement is
performed by the compiler, and I have no access to that implentación.
1) The solution can be: define an Java8 interface with methods
implemented
by default?
2) It is possible to access a Prototype implementation of
JQueryElement, by
example:
public class SwitchElement extends JQueryElement.Prototype{
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
But for this, it is necessary to use APT or the JsType generation
process,
is performed by APT.
I'm right, or very far from reality.
:)
El sábado, 4 de octubre de 2014 15:24:19 UTC-3, Ray Cromwell escribió:
Yes, but it will require Java8, which allows interfaces to contain
static methods. Here's how you'll do it soon when the Java8 stuff
lands:
@JsType
public interface ImageUtils {
public static Texture loadTexture(String url) { return
js($wnd.THREE.ImageUtils.loadTexture($0), url); }
}
ImageUtils.loadTexture(url);
On Sat, Oct 4, 2014 at 8:18 AM, confile michael@googlemail.com
wrote:
Consider the following static JavaScript function:
THREE.ImageUtils = {
loadTexture: function (url) { ... }
}
The way I use to create the static function with JsInterop is to
create
an
interface for ImageUtils and then create an inner abstract class
MyStatic
which contains the static methods implemented with JSNI.
Here is an example of the above class:
@JsType
public interface ImageUtils {
public static abstract class MyStatic {
public static native Texture create(String url) /*-{
return new
Re: [gwt-contrib] Re: GWT 2.7 release plan
There are a few things we need to do. I will talk with Andrei and see if we can make it. On Wed, Oct 8, 2014 at 7:54 AM, hypn...@donarproject.org wrote: Hi, thank you all for your hard work. We have been using GWT and SDM with great success in a big financial software company :). There is one major feature that is still not merged : NavigableMap https://gwt-review.googlesource.com/#/c/3650/ Will it be possible to have it in the 2.7 realease ? Thanks Le mercredi 1 octobre 2014 21:15:26 UTC+2, Daniel Kurka a écrit : Hi all, we just settled on a GWT 2.7 release plan: - We *code freeze* on *October 7th* and branch for GWT 2.7. - As soon as we have the *remaining patches submitted*, we put out a beta1 build, this should be no later than *October 7th.* - Putting out a *beta1 externally* allows us to collect feedback on the new super dev mode integration externally as well. - We are going to *flip incremental to default* tomorrow and *wait for 1-2 weeks* for google internal feedback, if there is no serious issues we are going to *put out RC1* - GWT 2.7 will still be compatible with Java 6. Patches / Fixes that need to go in: - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ ( dankurka) - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka). - Investigate why some people are seeing errors with incremental not restricting to one permutation (dankurka). - Public directories are not copied o the war directory when using SDM (skybrian). - Restore Java 6 compatibility (skybrian). - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse) Patches that are nice to have: - Improve exception logging in SDM (goktug). *If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.* -Daniel -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4e282093-c7f0-4b93-b802-d10002fe8af9%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/4e282093-c7f0-4b93-b802-d10002fe8af9%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA04K7MPzxhZqh6CXn7gDowe0-wDemJGDB1QeAFosTjCgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w/ overriding. To pick a case at random (ahem, GXT), say you want to override UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't change that return type, since you can't override methods and return a superclass (or a subclass of the superclass). If we assume that no downstream code ever subclasses and overrides any method that returns user.client.Element, yes, we can cut over cleanly in the future, you are right. But GXT notwithstanding, the SimplePanel class is meant to be subclassed and have getContainerElement() return a different container for the child - I'd be very surprised if there is no downstream code that does this somewhere. Example: FooLib v1 is compatible with GWT 2.5, when user.client.Element was not deprecated. It has a SimplePanel subclass called HeaderPanel, which overrides getContainerElement() to return a specific child element. GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with both GWT 2.5 and 2.6. As it should be. To catch up, FooLib v2 would like to remove usages of user.client.Element, but since SimplePanel.getContainerElement() still requires that return type, it can't. The best they can do is find all cases of user.client.Element and cast up to dom.client.Element from the return value of methods like getElement() and getContainerElement(). Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 was writing the cleanest possible code (returning a deprecated type). Not ideal. Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now has SimplePanel.getContainerElement return a supertype of user.client.Element, so subclasses are free to *further restrict* the return type (like v1/v2 is doing), or use the dom.client.Element. The v1 version will probably have issues if it uses the returned value from getContainerElement() as a user.client.Element, but v2 corrected that, so v2 now is compatible with GWT 2.6 and GWT 2.7. Win. Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and since v2 didn't use it any more, in this regard v2 is also compatible with GWT 2.8/3.0. Of course, this won't happen, some other API detail will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required resource tags causing warnings, etc). That's basically what I said too, right? Remove all uses of user.client.Element but keep the class around (or –better IMO– move it to a gwt-user-compat.jar) for downstream libraries. On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit- contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later removing the old one. Any library/project compatible with N is then compatible with N+1 in as many cases as possible. If we like b), I'd leave any static DOM methods, but dig in further and hit any overridable methods. If a) is preferred, we can just cut to the chase and remove user.client.Element entirely today. If we did things right in 2.6 (and I have no reason to think otherwise), user code (anything not from GWT proper,
[gwt-contrib] GWT 2.7
Hi!, Is there a easy way to download the GWT 2.7 SDK to help with the tests? Thanks! -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b1978df2-3328-4369-9b63-aa04a6237bd7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7
On Wednesday, October 8, 2014 6:49:30 PM UTC+2, Marcio Alves wrote: Hi!, Is there a easy way to download the GWT 2.7 SDK to help with the tests? Thanks! There are snapshots deployed nightly (when the build is green) to https://oss.sonatype.org/content/repositories/google-snapshots/ for use with Maven/Ivy/Gradle/etc. but no SDK as a ZIP file. It might be possible to configure build.gwtproject.org to expose the ZIP file of the lastSuccessfulBuild, as it is being built anyway, but I'm not sure we want to go there (could lead to a lot of traffic, particularly if people start scheduling daily downloads) -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/13477f07-c495-4e39-a889-776f67ac7e91%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com javascript: wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w/ overriding. To pick a case at random (ahem, GXT), say you want to override UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't change that return type, since you can't override methods and return a superclass (or a subclass of the superclass). If we assume that no downstream code ever subclasses and overrides any method that returns user.client.Element, yes, we can cut over cleanly in the future, you are right. But GXT notwithstanding, the SimplePanel class is meant to be subclassed and have getContainerElement() return a different container for the child - I'd be very surprised if there is no downstream code that does this somewhere. Example: FooLib v1 is compatible with GWT 2.5, when user.client.Element was not deprecated. It has a SimplePanel subclass called HeaderPanel, which overrides getContainerElement() to return a specific child element. GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with both GWT 2.5 and 2.6. As it should be. To catch up, FooLib v2 would like to remove usages of user.client.Element, but since SimplePanel.getContainerElement() still requires that return type, it can't. The best they can do is find all cases of user.client.Element and cast up to dom.client.Element from the return value of methods like getElement() and getContainerElement(). Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 was writing the cleanest possible code (returning a deprecated type). Not ideal. Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now has SimplePanel.getContainerElement return a supertype of user.client.Element, so subclasses are free to *further restrict* the return type (like v1/v2 is doing), or use the dom.client.Element. The v1 version will probably have issues if it uses the returned value from getContainerElement() as a user.client.Element, but v2 corrected that, so v2 now is compatible with GWT 2.6 and GWT 2.7. Win. Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and since v2 didn't use it any more, in this regard v2 is also compatible with GWT 2.8/3.0. Of course, this won't happen, some other API detail will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required resource tags causing warnings, etc). That's basically what I said too, right? Remove all uses of user.client.Element but keep the class around (or –better IMO– move it to a gwt-user-compat.jar) for downstream libraries. Okay, call it mixed messages then. I'll update the patch to go further in this direction, so that user.client.Element exists, but is unused in 2.7, and we can kill it in the next version. Do we have a plan for a gwt-user-compat v2.7.0? Seems a bit silly to make one for a single class... On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit- contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later
