Un-imported GwtQuery on the classpath causes errors

[niloc132]

A strict project without an <inherits> statements on Query but with an <inherits> on RequestFactory will fail to compile. Since com.google.web.bindery.requestfactory.shared.gquery.PromiseRF lives in the RequestFactory package and extends com.google.gwt.query.client.plugins.deferred.Deferred.DeferredPromiseImpl, when GWT attempts to compile it it fails.

As a result, it is not possible to have a module in a project that does not inherit Query, yet has it on the classpath.

Workarounds

• avoid having gwt-query as a dependency except for projects that actually intend to use it, or
• gratuitously inherit Query anywhere RequestFactory is used, or
• give up on -strict

[jDramaix]

Thanks for reporting. I think it's a consequence of the fix made there : https://github.com/gwtquery/gwtquery/issues/237

[niloc132]

Thanks - I'm playing with adding GQuery to http://viola.colinalworth.com/, but this issue makes it tricky to do so without assuming that all users will want it, or building a custom classpath based on detected/declared dependencies.

[jDramaix]

Awesome idea colin !

For the issue I don't see a immediate straightforward solution. Your use case (having GQuery on classpath but not using it) is very specific to your fiddle.

A possible solution would be to have a separate jar containing all RF stuffs (maven can maybe do that easily). So you will be able to include a "light" version of GQuery in your classpath with the constraint that people can not use the PromiseRF I think in the long term a custom classpath based on detected/declared dependencies is the best solution.

[niloc132]

A real life use case would be a single Maven module with two GWT modules. One uses GQuery, the other does not, but it does use RequestFactory. As mentioned, a 'fix' would be to turn off strict, or to inherit and never use Query, but neither of those is actually a fix.

I'm trying very hard to stay away from removing classpath entries on a running build agent, since that means re-loading the classes once they are used again. A significant performance bump is obvious from keeping classes loaded and hot in the compiler itself as well as allowing it to cache module defs - I'd rather not have to give up all of those gains for one library. It will be necessary to do such classpath rearranging if I am able to support different versions of the same libraries, but to get to that point I'll need to have each library version explicitly declare all dependencies (and may end up looking a lot like Eclipse with its terrible dependency resolution dialogs).

[manolo]

I dont think so much people is using the promises RF helper causing the issue. So IMO it is perfectly doable if we extract that class to a jar and probably move it to a different namespace like it was at the beginning. The cause of the issue is that RF is part of GWT but delivered in a different jar, if someday GWT splits components in different dependencies (i18n, widgets, RPC, autobeans, etc) we will coming back to this issue in many gwt projects.