OK, so I've posted a bunch more patches, using different optimizations:
- DeadCodeElimination: to optimize out the monomorphic String.toString
calls (String.toString is back to a JSNI String(this) to make sure it
behaves correctly, as I'm afraid the ""+this in Java from the second
code patch coul
Steven,
The issue seems to be that there is no way of instructing GWT which jars
are even relevant to GWT. My project is fairly large and depends on a
large set of server-side libraries that are on the classpath, but will
never change on a refresh, and even if they were to change, would not
i
I suggest moving the aria stuff out of client/ui. Maybe
com.google.gwt.aria?
http://gwt-code-reviews.appspot.com/1624803/diff/1/user/src/com/google/gwt/user/cellview/client/SimplePager.java
File user/src/com/google/gwt/user/cellview/client/SimplePager.java
(right):
http://gwt-code-reviews.apps
For a "fairly large" project, you'd probably better have separate server and
client (and shared) projects.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
You mean going the -noserver route? I like the convenience of starting the
entire app within Jetty in dev mode. How about allowing a descriptor that
specifies the jars required by GWT?
Most apps probably require at most a handful of third-party GWT jars but
have a large number of jars required by
The main reason is to allow the ARIA library to be used independent of
the widget library, in case you write an app the uses the low level DOM
library but not widgets.
We've been moving away from using client.ui as a catch-all for all UI
related things in favor or segregated packages for differen
On Thursday, January 5, 2012 8:22:36 PM UTC+1, Sanjiv Jivan wrote:
>
> You mean going the -noserver route? I like the convenience of starting the
> entire app within Jetty in dev mode. How about allowing a descriptor that
> specifies the jars required by GWT?
Client-side and server-side class
I agree with Sanjiv. I have many eclipse projects, however, it is the
non-gwt dependencies that *SEEM* to be responsible for the majority of the
slowdown/issue with refresh. As I said at the beginning, there may have
been things that I could have done to architect better, but I shouldn't
have
Thomas,
Perhaps you can help me a little further. I am actually using maven
(m2eclipse), and the GPE, so I'm not really sure if this is contributing to
my problem. How does the server-side classpath get loaded from a different
source?
--
http://groups.google.com/group/Google-Web-Toolkit-Con
The server-side classpath is loaded from the war/WEB-INF/lib (with a
fallback to the classpath of the DevMode, which prints a warning).
If you're using Maven, it's actually even easier to get your dependencies
right there in the WEB-INF/lib:
http://code.google.com/eclipse/docs/faq.html#gwt_with
http://gwt-code-reviews.appspot.com/1620805/diff/8001/dev/core/src/com/google/gwt/dev/shell/rewrite/RewriteJsniMethods.java
File
dev/core/src/com/google/gwt/dev/shell/rewrite/RewriteJsniMethods.java
(right):
http://gwt-code-reviews.appspot.com/1620805/diff/8001/dev/core/src/com/google/gwt/dev/sh
In this case, using a third-party servlet container (Jetty or Tomcat, or
even a Glassfish or JBoss; Jetty has the advantage over Tomcat of really
fast hot-deployment: you just have to "touch" an XML context file, with the
appropriate config; I can't tell for other containers and app servers) and
http://gwt-code-reviews.appspot.com/1620805/diff/12001/dev/core/src/com/google/gwt/dev/shell/JavaScriptHost.java
File dev/core/src/com/google/gwt/dev/shell/JavaScriptHost.java (right):
http://gwt-code-reviews.appspot.com/1620805/diff/12001/dev/core/src/com/google/gwt/dev/shell/JavaScriptHost.jav
13 matches
Mail list logo
