transitive dependency on GWT 2.6.0 about gwteventbinder HOT 6 CLOSED

EventBinder does depend on gwt-user, there's no reason to exclude it (either in your build.gradle or in EventBinder's POM).

It might be something strange/bad happening when using the so called “automatic dependency management” (i;e. gwtVersion) of the gwt-gradle-plugin, but that's due to the gwt-gradle-plugin then, and nothing to do with EventBinder. It is very likely that many other libs will have dependencies on gwt-user.

from gwteventbinder.

Your parent POM has an explicit dependency for version 2.6.0 and gwt-user isn't marked as provided/optional... (not sure how that is supposed to work for maven lib projects)?

from gwteventbinder.

Yeah this seems right to me, though maybe it would make sense to mark the dependency as provided since the user is almost certainly going to depend on GWT also? I'm not exactly sure what the best practices around provided are.

What problem is this causing for you? In the past when I've used Gradle on a project that has transitive dependencies on multiple versions of the same library, it just resolves to use the highest version of that library everywhere. This should work fine with EventBinder as far as I know.

from gwteventbinder.

In the past when I've used Gradle on a project that has transitive dependencies on multiple versions of the same library, it just resolves to use the highest version of that library everywhere.

Exactly, and this is how it should work. This is why I think that there's a problem (bug) with the gwt-gradle-plugin and how it handles GWT dependencies: in https://github.com/steffenschaefer/gwt-gradle-plugin/blob/release-0.6/gwt-gradle-plugin/src/main/java/de/richsource/gradle/plugins/gwt/GwtBasePlugin.java#L84-L88 you can see that it does a union of the gwt and gwtSdk configuration files (i.e. after the dependencies are resolved), so you can easily end up with duplicate gwt-user JARs. This is then added to the compile classpath, possibly leading to other duplicates with the compile and testCompile configurations. Instead, configurations should extend one another so that only one version of each dependency is ever resolved and ends up in the classpath.

from gwteventbinder.

I end up with gwt-user-2.6.0 as a compile dependency which results in a
compile failure for my 2.7.0 or later projects. It seems to show up as a
full build dependency and not as a "provided dependency".

On Tue, Aug 25, 2015 at 1:11 AM, Erik Kuefler [email protected]
wrote:

Yeah this seems right to me, though maybe it would make sense to mark the
dependency as provided since the user is almost certainly going to depend
on GWT also? I'm not exactly sure what the best practices around provided
are.

What problem is this causing for you? In the past when I've used Gradle on
a project that has transitive dependencies on multiple versions of the same
library, it just resolves to use the highest version of that library
everywhere. This should work fine with EventBinder as far as I know.

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

• Learn to the Cherokee language: http://jalagigawoni.gnomio.com/

from gwteventbinder.

As I said above, it's (IMO) a bug in the gwt-gradle-plugin. Workarounds include:

• disabling so-called “Automatic dependency management” of the GWT dependencies (gwtVersion), instead declaring dependencies yourself (and declaring then in the gwt configuration rather than gwtSdk so that resolution works as expected)
• explicitly declare gwt-user (and possibly gwt-dev) in the gwt configuration to "fix" dependency resolution (you'll end up with a duplicate gwt-user JAR in the classpath too, but at least versions will match)
• fine-tune Gradle's dependency resolution to force the use of GWT 2.7; either use force 'com.google.gwt:gwt-user:2.7.0' or a dependency resolve rule
• exclude the transitive gwt-user as you're currently doing.

It remains that the bug is in gwt-gradle-plugin, and gwteventbinder is OK.

from gwteventbinder.