[gwt-contrib] Re: help needed on gwt-maven-plugin
The same script can run the shell with a inlined classpath : set CLASSPATH=D:\platina\repository\com\google\gwt\gwt-user\1.5.3\gwt-user-1.5.3.jar;D:\platina\repository\com\google\gwt\gwt-dev\1.5.3\gwt-dev-1.5.3-windows.jar ... java -cp %CLASSPATH% -Dcatalina.base=D:\projets\apache\gwt-maven-plugin\target\it\gwt-compile\target\tomcat com.google.gwt.dev.GWTShell -gen ... But this option fails on windows whith command line limitation on large projects with lot's of dependencies. So I don't thing this issue is related to some jarjar packaging. It seems the TomcatEmbedded doesn't support to run inside a hierarchized classloader (looks really strange) and is fine only when all dependencies are set in the Classpath. 2009/1/21 Scott Blum sco...@google.com Jarjar is a trunk issue that I believe is unrelated. On Tue, Jan 20, 2009 at 10:08 PM, John Tamplin j...@google.com wrote: On Tue, Jan 20, 2009 at 9:41 PM, Scott Blum sco...@google.com wrote: Thanks, nicolas. Your test reproduced an issue, but I was unable to get Tomcat to work properly. We will probably not fix this for 1.6 since Jetty works fine. http://code.google.com/p/google-web-toolkit/issues/detail?id=1032 Actually, I think jetty has a similar issue (see the internal error report Lex is looking at) -- I think the root cause is jarjar missed some reflective references to classes, so code is looking for classes under the un-mangled name yet the classes have been renamed inside our jar. Can you try it with surpressing the jarjar mangling? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: help needed on gwt-maven-plugin
Hi, I wrote a blog post about this exact subject here: http://development.lombardi.com/?p=380 I believe this will help. My understanding is that EmbeddedTomcatServer doesn't set up the ClassLoader as you would expect. Thanks, Olivier. On Jan 21, 2:17 am, nicolas de loof nicolas.del...@gmail.com wrote: The same script can run the shell with a inlined classpath : set CLASSPATH=D:\platina\repository\com\google\gwt\gwt-user\1.5.3\gwt-user-1.5.3.jar;D:\platina\repository\com\google\gwt\gwt-dev\1.5.3\gwt-dev-1.5.3-windows.jar ... java -cp %CLASSPATH% -Dcatalina.base=D:\projets\apache\gwt-maven-plugin\target\it\gwt-compile\target\tomcat com.google.gwt.dev.GWTShell -gen ... But this option fails on windows whith command line limitation on large projects with lot's of dependencies. So I don't thing this issue is related to some jarjar packaging. It seems the TomcatEmbedded doesn't support to run inside a hierarchized classloader (looks really strange) and is fine only when all dependencies are set in the Classpath. 2009/1/21 Scott Blum sco...@google.com Jarjar is a trunk issue that I believe is unrelated. On Tue, Jan 20, 2009 at 10:08 PM, John Tamplin j...@google.com wrote: On Tue, Jan 20, 2009 at 9:41 PM, Scott Blum sco...@google.com wrote: Thanks, nicolas. Your test reproduced an issue, but I was unable to get Tomcat to work properly. We will probably not fix this for 1.6 since Jetty works fine. http://code.google.com/p/google-web-toolkit/issues/detail?id=1032 Actually, I think jetty has a similar issue (see the internal error report Lex is looking at) -- I think the root cause is jarjar missed some reflective references to classes, so code is looking for classes under the un-mangled name yet the classes have been renamed inside our jar. Can you try it with surpressing the jarjar mangling? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4508 - releases/1.6/user/test/com/google/gwt/user/client
Author: j...@google.com
Date: Wed Jan 21 09:50:06 2009
New Revision: 4508
Modified:
releases/1.6/user/test/com/google/gwt/user/client/CommandExecutorTest.java
Log:
Fixes 1.6 build breakage. CommandExecutorTest was allowing an exception to
escape from the test method that was exposed by recent fixes to the JUnit
infrastructure.
Modified:
releases/1.6/user/test/com/google/gwt/user/client/CommandExecutorTest.java
==
---
releases/1.6/user/test/com/google/gwt/user/client/CommandExecutorTest.java
(original)
+++
releases/1.6/user/test/com/google/gwt/user/client/CommandExecutorTest.java
Wed Jan 21 09:50:06 2009
@@ -206,7 +206,7 @@
UncaughtExceptionHandler ueh1 = new UncaughtExceptionHandler() {
public void onUncaughtException(Throwable e) {
-if (!(e instanceof CommandCanceledException)) {
+if (!(e instanceof CommandCanceledException || e instanceof
IncrementalCommandCanceledException)) {
originalUEH.onUncaughtException(e);
return;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Code Review for 1.6: Removes unused HasHandlers#isEventHandled
Reviewers: jgw, ecc, Description: This patch gets rid of the unused isEventHandled call on the new HasHandlers interface. It is meant to be applied to the releases/1.6 branch. Please review this at http://gwt-code-reviews.appspot.com/2209 Affected files: user/src/com/google/gwt/event/shared/HandlerManager.java user/src/com/google/gwt/event/shared/HasHandlers.java user/src/com/google/gwt/user/client/impl/HistoryImpl.java user/src/com/google/gwt/user/client/ui/Widget.java user/test/com/google/gwt/event/shared/HandlerManagerTest.java user/test/com/google/gwt/user/datepicker/client/DateChangeEventTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] CSS for ScrollTable out of date
Hello everyone, I've tried to play around with the gen2 ScrollTable and I found that the CSS posted here: http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable doesn't work. thomas.husfeldt commented 7 comments from the bottom with some updated CSS that sort of works (not as nice as the demo). Is there any CSS available that works with the gen2 ScrollTable? Thank you. Regards, -- Arthur Kalmenson --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: CSS for ScrollTable out of date
You can use the CSS from the gen2 demo: http://code.google.com/p/google-web-toolkit-incubator/source/browse/trunk/src/com/google/gwt/demos/scrolltable/public/ScrollTableDemo.css And the image: http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/trunk/src/com/google/gwt/demos/scrolltable/public/images%3Fstate%3Dclosed Hope this helps. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 21, 2009 at 3:02 PM, Arthur Kalmenson arthur.k...@gmail.comwrote: Hello everyone, I've tried to play around with the gen2 ScrollTable and I found that the CSS posted here: http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable doesn't work. thomas.husfeldt commented 7 comments from the bottom with some updated CSS that sort of works (not as nice as the demo). Is there any CSS available that works with the gen2 ScrollTable? Thank you. Regards, -- Arthur Kalmenson --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review for 1.6: Removes unused HasHandlers#isEventHandled
On 2009/01/21 19:04:33, rjrjr wrote: LGTM. I can't think of any use case that really justifies adding this extra complexity to the HasHandlers interface (certainly not one that couldn't be easily worked around). The fact that there are no callers anywhere in the system makes that even more clear to me. http://gwt-code-reviews.appspot.com/2209 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5.3: Type mismatch with enum in parameterized class.
Isaac, I would put money on our updating to a newer version of JDT. I'd
find where Lex committed this upgrade... if there are no code changes, you
might try putting the newer JDT higher on the classpath as a test. If that
works, simple jar surgery should get you where you want to go.
On Wed, Jan 21, 2009 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I've found an interesting error in GWT 1.5.3:
[ERROR] Line 14: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
[ERROR] Line 17: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
Compiling module test.Test
Computing all possible rebind results for 'test.client.Test'
Rebinding test.client.Test
Checking rule generate-with
class='com.google.gwt.user.rebind.ui.ImageBun
dleGenerator'/
[ERROR] Unable to find type 'test.client.Test'
[ERROR] Hint: Previous compiler errors may have made this type
unava
ilable
[ERROR] Hint: Check the inheritance chain from your module; it
may n
ot be inheriting a required module or a module may not be adding its source
path
entries properly
To reproduce:
public class Test implements EntryPoint {
static class ParametricT {
enum Numbers {
ONE, TWO;
}
}
public void onModuleLoad() {
switch (Parametric.Numbers.valueOf(ONE)) {
case ONE: // Line 14
System.out.println(ONE);
break;
case TWO: // Line 17
System.out.println(ONE);
break;
}
}
}
Removing the parameter from the type enclosing the enum fixes the problem.
The above *works* in trunk and 1.6, but I searched a little bit and I
couldn't find anything in the issue tracker that appeared related.
Upgrading to 1.6/trunk isn't a good option for me at the moment, so
I'm hoping that someone has seen this before and could help me find
the change that fixed it. If it's a simple patch, I can apply it to
1.5.3 until such time as an upgrade is possible. Moving the enum to a
non-parameterized type would probably work as well, but I'm loathe to
do too much redesign on account of a compiler bug that appears to
already have been fixed.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5.3: Type mismatch with enum in parameterized class.
In terms of the GWT 1.5 code line, we're very unlikely to actually release a
1.5.4...GWT 1.6 is just around the corner.
On Wed, Jan 21, 2009 at 6:55 PM, Scott Blum sco...@google.com wrote:
Isaac, I would put money on our updating to a newer version of JDT. I'd
find where Lex committed this upgrade... if there are no code changes, you
might try putting the newer JDT higher on the classpath as a test. If that
works, simple jar surgery should get you where you want to go.
On Wed, Jan 21, 2009 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I've found an interesting error in GWT 1.5.3:
[ERROR] Line 14: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
[ERROR] Line 17: Type mismatch: cannot convert from
Test.Parametric.Number
s to Test.ParametricT.Numbers
Compiling module test.Test
Computing all possible rebind results for 'test.client.Test'
Rebinding test.client.Test
Checking rule generate-with
class='com.google.gwt.user.rebind.ui.ImageBun
dleGenerator'/
[ERROR] Unable to find type 'test.client.Test'
[ERROR] Hint: Previous compiler errors may have made this type
unava
ilable
[ERROR] Hint: Check the inheritance chain from your module; it
may n
ot be inheriting a required module or a module may not be adding its
source path
entries properly
To reproduce:
public class Test implements EntryPoint {
static class ParametricT {
enum Numbers {
ONE, TWO;
}
}
public void onModuleLoad() {
switch (Parametric.Numbers.valueOf(ONE)) {
case ONE: // Line 14
System.out.println(ONE);
break;
case TWO: // Line 17
System.out.println(ONE);
break;
}
}
}
Removing the parameter from the type enclosing the enum fixes the problem.
The above *works* in trunk and 1.6, but I searched a little bit and I
couldn't find anything in the issue tracker that appeared related.
Upgrading to 1.6/trunk isn't a good option for me at the moment, so
I'm hoping that someone has seen this before and could help me find
the change that fixed it. If it's a simple patch, I can apply it to
1.5.3 until such time as an upgrade is possible. Moving the enum to a
non-parameterized type would probably work as well, but I'm loathe to
do too much redesign on account of a compiler bug that appears to
already have been fixed.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review for 1.6: Removes unused HasHandlers#isEventHandled
Committed to releases/1.6 @r4509 On 2009/01/21 21:46:53, jgw wrote: On 2009/01/21 19:04:33, rjrjr wrote: LGTM. I can't think of any use case that really justifies adding this extra complexity to the HasHandlers interface (certainly not one that couldn't be easily worked around). The fact that there are no callers anywhere in the system makes that even more clear to me. http://gwt-code-reviews.appspot.com/2209 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] TBR Incubator review for HasHandlers breakage
Fix submitted TBR emily at incubator r1432. Fixes breakage due to HasHandlers change from gwt r4494 rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
I spent quite a bit of time trying out this new permutation worker framework (mostly spent stepping through it in my debugger, as I was having issues). Here are my thoughts: 1). The mechanism for designating the number of threads or processes needs to be cleaned up or rethought. The parameter -localWorkers N ends up spawning 1 ThreadedPermutationWorker and N-1 ExternalPermutationWorkers. This is counter-intuitive, because when I set something to N, I'm expecting to see N homogeneous objects. That's because if you don't specify a value for gwt.jjs.permutationWorkerFactory, the default is to start creating threaded workers up to maxThreads and use external workers for the rest. I have a dual-core CPU, so I wanted to use 2 threads. I eventually figured out that the way to accomplish this is to either a). set -Dgwt.jjs.maxThreads=2 *and* -localWorkers 2 simultaneously, or b). set - Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactoryand -localWorkers 2 A better way of managing this would be to have two command-line parameters, nProcesses and n nThreadsPerProcess. 2). I couldn't get ExternalPermutationWorkerFactory to work: java.net.ConnectException: Connection refused: connect at com.google.gwt.dev.CompilePermsServer.run (CompilePermsServer.java:243) 3). Finally, I'm sorry to say this, but this framework is mostly useless if you have fewer than 8 cores and more than one module to compile. There is very little performance gain when I compile with 2 threads instead of 1 (only 10% per module on a dual-core CPU with 5 permutations per module). Although the permutations can now be compiled using possibly more than one thread, the modules are still processed sequentially. If you have more than one output module (and I suspect most developers for whom compiler speed is an issue fall into this category), then it's much faster to run the compiler in parallel (i.e. invoke multiple instances of the complier with 1 module each, instead of one compiler process with a list of modules). This gives you a 100% boost on a dual-core CPU. I've been doing this using the ForTask from ant- contrib for the past half year and it halved my build time. In other words, the task of compiling modules is embarrassingly parallel, but the the task of generating permutations within a module doesn't seem to be so. So basically, as much as this new framework looks cool, it's totally useless to me when I have to build more than one module. If I had a computer with 2 quad-core CPUs (like Bob ;) ), on the other hand, I might spawn 2 compiler instances with 4 threads each. Some food for thought here - perhaps you should think about using the external workers for modules and threads for permutations. Alex On Jan 21, 6:45 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: This stuff looks great, guys. Is there any chance of actually setting up a distributed build cluster using this code? Back when I had an older laptop, I've thought about the idea of spawning one or more EC2 instances to do builds. Now, with a top of the line laptop, I was happy for a while, but I still only have 2 cores, and build times are starting to bother me again. On Nov 24 2008, 12:00 pm, Lex Spoon sp...@google.com wrote: On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum sco...@google.com wrote: - We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he was physically here, and I think both of the TPE-based implementations suck. Well, we eliminated TPE itself. However, we went with message-passing coordination rather than checking multiple counters and queues and/or checking the interrupted states. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWTCanvas and ImageBundle,
Jaime, If clipping is supported, then I believe you can get the required information from the Image interface: Image.getUrl() Image.getOriginalLeft() Image.getOriginalTop() Image.getHeight() Image.getWidth() With these methods, you should be able to construct a regular Image/IMG and then use the rectangle bounded by getOriginalLeft/Top/Height/Width as the clipping region. -Ray On Tue, Jan 20, 2009 at 2:19 PM, Jaime Yap jaime...@google.com wrote: Ray nailed it mostly. You can (as of 5 minutes ago) clip from a source image in GWTCanvas. However, you will notice that GWTCanvas drawImage() expects a regular ImageElement. ImageBundle uses background image slicing and other trickery that varies by browser. You can do some magic to tease the underlying DOM element out of an ImageBundle's AbstractImagePrototype for a specific image, but you have no guarantee as to what exactly that DOM element is. For example, on IE the DOM structure is totally different. What you could do is use GWTCanvas to clip out the actual image that the ImageBundle generator spits out. But you would need to first get a hold of it as a regular ImageElement which means knowing the URL to the image and loading it. If I am not mistaken that file is named according to its hash string (?), so you would need some means of grabbing the URL of the generated ImageBundle image. So in other words, you can't use GWTCanvas with ImageBundles or AbstractImagePrototype directly, BUT you can use it on an image that has been bundled together. -Jaime On Tue, Jan 20, 2009 at 4:15 PM, Ray Cromwell cromwell...@gmail.com wrote: I don't think you can, at least not easily. To do this requires the drawImage() call which allows specifying the source rectangle. GWTCanvas doesn't support clipping either, so you can't set a rectangle path, and clip the source image. This might be due to a limitation of IE/VML, I dunno, I try to stay away from VML. -Ray On Tue, Jan 20, 2009 at 1:00 PM, Axel Kittenberger axe...@gmail.com wrote: Can I (and if yes how) use ImageBundle images in GWTCanvas.drawImage ()? Kind regards, Axel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
