Two versions of a dependency are used

Help/Discuss
1

Can someone please explain why Gradle does not show all dependencies via ./gradlew dependencies? I define the dependency “org.eclipse.emf:org.eclipse.emf.ecore:2.15.0” but Gradle downloaded version 2.12.0 and 2.15.0 (I have cleared the cache before). ./gradlew dependencies only outputs org.eclipse.emf:org.eclipse.emf.ecore:2.12.0 -> 2.15.0 which means that only version 2.12.0 is used, right?

3

org.eclipse.emf:org.eclipse.emf.ecore:2.12.0 → 2.15.0

This means that there was a dependency conflict where there are two versions of the dependency in your dependency graph. Gradle has resolved the conflict by choosing the latest (it chose 2.15.0 instead of 2.12.0)

which means that only version 2.12.0 is used, right?

Incorrect, 2.15.0 will be used unless you override the default resolution strategy

1 Like
4

What I don’t get is why both versions are downloaded and version 2.12.0 is picked up during gradle jar. My build failed because of that and I have to override the resolution strategy to mitigate this problem (it took me some time to figure it out). I have expected to see somewhere (e.g. via gradle dependencies) that the wrong version has been chosen.

5

Perhaps the dependencyInsight task can help show you where the other version is coming from

6

Thx, but also dependencyInsight shows version 2.15.0…

7

Sorry to ask a silly question… but are you executing these tasks (dependencies & dependencyInsight) against the same module which is failing? Eg:

gradle :failingModule:dependencyInsight ...

8

What do you mean by failingmodule? I have only one project and the library calling the function from 2.15.0 is org.eclipse.emf:org.eclipse.emf.ecore.xcore:1.7.0. I get the following error message (without overriding the default resolution strategy) indicating that version 2.12.0 has been used.

> Task :generateXtext FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateXtext'.
> org.eclipse.emf.ecore.util.EcoreValidator$EGenericTypeBuilder.buildEGenericType(Ljava/lang/String;)Lorg/eclipse/emf/ecore/EGenericType;
9

What do you mean by failingmodule ?

I was trying to rule out the possibility of a multi-module build where you were running the tasks aginst the wrong module. Since it’s single module build we can stop that line of questioning

Task :generateXtext FAILED

Ah, I was assuming that this was a compile/testRuntime issue. Since it’s a generateXXX task I’m guessing it’s a buildscript classpath issue.

Can you please show me

  1. The place where generateXtext task is declared (if this comes from a plugin then share the plugin declaration)
  2. The place where you declare org.eclipse.emf:org.eclipse.emf.ecore:2.15.0 in your dependencies

Other things which could help are

  1. Sharing a build scan via --scan (note this may expose internal details to the public, ensure this is allowed)
  2. Sharing snippets from the profile report via --profile
  3. Share a minimal project demonstrating the issue (removing unrelated detail from your build.gradle)

See command line options

10

Thanks for your help. I have made a minimal working example and removed everything not needed.

./gradlew --no-daemon jar shows the error message.

./gradlew --no-daemon dependencies | grep 2.12 says org.eclipse.emf:org.eclipse.emf.ecore:2.12.0 -> 2.15.0 although version 2.12.0 gets loaded.

dependency-problem.zip (53.0 KB)

11

For the benefit of those folks playing along at home, here’s the interesting bits from build.gradle

plugins {
  id "org.xtext.builder" version "2.0.2"
}
// uncommenting this out and everything works but why???
/*
 configurations.all {
     resolutionStrategy {
         force "org.eclipse.emf:org.eclipse.emf.ecore:2.15.0"
     }
 }
*/
dependencies {
    compile "org.eclipse.xtext:org.eclipse.xtext.xbase.lib:2.15.0"
    compile "org.eclipse.emf:org.eclipse.emf.ecore.xcore.lib:1.3.0"
    compile "org.eclipse.emf:org.eclipse.emf.ecore.xmi:2.15.0"

    xtextLanguages "org.eclipse.xtext:org.eclipse.xtext.ecore:2.15.0"
    xtextLanguages "org.eclipse.emf:org.eclipse.emf.codegen.ecore.xtext:1.4.0"
    xtextLanguages ("org.eclipse.emf:org.eclipse.emf.ecore.xcore:1.7.0"){
        exclude group: 'org.antlr', module: 'antlr-runtime'
    }
}
12

Ok, I ran a build scan and this is what it showed

build-scan-dependencies
build-scan-dependencies.png791×696 89.2 KB

This shows the issue in xtextToolingMain

xtextToolingMain - 0.134s
   org.eclipse.emf:org.eclipse.emf.ecore:2.12.0
   org.eclipse.emf:org.eclipse.emf.ecore.xmi:2.12.0

So I tried solving by

dependencies {
   xtextToolingMain 'org.eclipse.emf:org.eclipse.emf.ecore:2.15.0'
   xtextToolingMain 'org.eclipse.emf:org.eclipse.emf.ecore.xmi:2.15.0'
}

But I get

* What went wrong:
A problem occurred evaluating root project 'dependency-problem'.
> Could not find method xtextToolingMain() for arguments [...]

So it seems that the xtextToolingMain configuration is created at execution time rather than at configuration time which is why the dependency* tasks weren’t showing it.

The following code fixes the issue because DomainObjectCollection.all(Closure) is a “live” operation so any Configuration instances added to the container will have the closure applied to them, including future operations

 configurations.all {
     if (name == 'xtextToolingMain') {
         resolutionStrategy {
             force "org.eclipse.emf:org.eclipse.emf.ecore:2.15.0"
         }
     }
 }

It’s possible that you can specify some extra config to the plugin to change the underlying version (eg jacoco plugin accepts a toolVersion to override the default jacoco version).

I suggest you take a look at the plugin documentation to see if it’s configurable. If it’s not configurable you might consider raising an issue on the plugin’s github repo to make the version configurable

13

Ahaaa! Thx for clarifying…