Re: [gwt-contrib] Re: Not able to run GWTTestCase
On the Eclipse side, I'd check whether the Jetty dependency is exported by the gwt-dev project. If it's not, then it won't be on the classpath of tests from the gwt-user project. It might be that we failed to properly update the Eclipse config files when updating Jetty (it does work for me, but I'm using a very old Eclipse workspace, and maybe Eclipse caches those things somewhere) On Thursday, February 13, 2014 11:33:12 PM UTC+1, Brian Slesinsky wrote: I'm not an Eclipse user, but we did upgrade to Jetty 8.1 in 2.6 and its package changed. If you put the new version of Jetty in your classpath that will probably fix it. - Brian On Thu, Feb 13, 2014 at 6:44 AM, Stephan Beutel stephan...@gmail.comjavascript: wrote: I also tried it with the Eclipse 3.8 and end up at the same point. I'm not able to run any GWTTestCase. Am Mittwoch, 12. Februar 2014 12:17:55 UTC+1 schrieb Stephan Beutel: Hello, I set up my Eclipse to contribute to GWT and worked through the Readme to set up an Eclipse workspace. All errors are gone in my Eclipse (Springsource Toolsuite) now, but I'm not able to run any GWTTestCase from within my Eclipse. The Ant build runs successfully. When trying to run any GWTTestCase I get this error: java.lang.Error: Unresolved compilation problems: The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved The import org.eclipse.jetty cannot be resolved AbstractLifeCycle cannot be resolved to a type RequestLog cannot be resolved to a type Request cannot be resolved to a type Response cannot be resolved to a type AbstractHttpConnection cannot be resolved to a type HttpFields cannot be resolved to a type Field cannot be resolved to a type Logger cannot be resolved to a type Logger cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Log cannot be resolved WebAppContext cannot be resolved to a type Server cannot be resolved to a type WebAppContext cannot be resolved to a type Server cannot be resolved to a type Log cannot be resolved Log cannot be resolved Server cannot be resolved to a type Server cannot be resolved to a type Log cannot be resolved WebAppContext cannot be resolved to a type WebAppClassLoader cannot be resolved to a type The method findResource(String) of type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension must override or implement a supertype method WebAppClassLoader cannot be resolved to a type WebAppClassLoader cannot be resolved to a type The method findClass(String) of type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension must override or implement a supertype method WebAppClassLoader cannot be resolved to a type The method isServerClass(String) is undefined for the type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension WebAppClassLoader cannot be resolved to a type The method addClassPath(String) is undefined for the type JettyLauncher. WebAppContextWithReload.WebAppClassLoaderExtension The method getInitParams() is undefined for the type JettyLauncher. WebAppContextWithReload The method setParentLoaderPriority(boolean) is undefined for the type JettyLauncher.WebAppContextWithReload The method isSystemClass(String) of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method WebAppContext cannot be resolved to a type The method doStart() of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method The method setClassLoader(JettyLauncher.WebAppContextWithReload.WebAppClassLoaderExtension) is undefined for the type JettyLauncher.WebAppContextWithReload WebAppContext cannot be resolved to a type The method doStop() of type JettyLauncher.WebAppContextWithReload must override or implement a supertype method WebAppContext cannot be resolved to a type The method getClassLoader() is undefined for the type JettyLauncher. WebAppContextWithReload The method setClassLoader(null) is undefined for the type JettyLauncher.WebAppContextWithReload AbstractConnector cannot be
[gwt-contrib] Re: bug in permutations.js?
Here is the difference in the generated JS. From a ~10/2013 trunk build:
function com_google_gwt_dom_client_StyleInjector_StyleInjectorImpl(){
switch (permutationId) {
case 1:
case 2:
case 3:
return new StyleInjector$StyleInjectorImplIE_0;
}
return new StyleInjector$StyleInjectorImpl_0;
}
So, even when permutationId was undefined (which it was for gecko_18,
which was basically permutation 0), it was fine, it'd get the non-IE
version.
But now with 2.6:
function com_google_gwt_dom_client_StyleInjector_StyleInjectorImpl(){
switch (permutationId) {
case 0:
case 4:
return new StyleInjector$StyleInjectorImpl_0;
}
return new StyleInjector$StyleInjectorImplIE_0;
}
The output changed; now when permutationId is undefined, which it still
is for gecko_1.8 (no change there), then IE is the default.
AFAICT the DOM.gwt.xml rules for StyleInjector haven't changed
recently. The permutations.js hasn't changed (permutationId was
undefined both pre-/post-2.6).
So, I can file a patch to make permutationId=0, but any ideas why this
would have changed since October-ish?
It must have been that, previously, case 0 would never have been put
inside the runtime switch statement, and instead always have been the
fallback.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] bug in permutations.js?
Yes it sounds like a bug. Want to add that to the issue tracker? https://code.google.com/p/google-web-toolkit/issues/detail?id=8575 I've verified that the patch fixes the behavior in our application. Any good suggestions about how to test this? Or volunteers to review the patch? Given it was, I assume, a bug in permutations.js, I imagine I would have to create a mini test app with collapse-all-properties, have it compile to JS, and then somehow verify that the right deferred binding for permutation 0 (which ever browser that happened to be) got the right selection. Thanks, Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] bug in permutations.js?
Maybe turn on soft permutations in a sample app, since we do at least test those manually before a release. Long-term, I'd like to see us using soft permutations by default, perhaps to collapse some browser permutations. If it were more commonly used then we'd likely notice that it's broken pretty quickly. - Brian On Fri, Feb 14, 2014 at 2:32 PM, Stephen Haberman step...@exigencecorp.comwrote: Yes it sounds like a bug. Want to add that to the issue tracker? https://code.google.com/p/google-web-toolkit/issues/detail?id=8575 I've verified that the patch fixes the behavior in our application. Any good suggestions about how to test this? Or volunteers to review the patch? Given it was, I assume, a bug in permutations.js, I imagine I would have to create a mini test app with collapse-all-properties, have it compile to JS, and then somehow verify that the right deferred binding for permutation 0 (which ever browser that happened to be) got the right selection. Thanks, Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
