Gradle 1.4, broken dependencies in multi project


(Carlo Luib-Finetti) #1

I just installed Gradle 1.4 and ran it against my multiproject definitions. Gradle 1.4 complains “Could not resolve all dependencies for configuration…” on 3rd party libraries, whereas Gradle 1.3 works very well (of course I did a rerun with Gradle 1.3).

I defined all my 3rd party dependencies with symbolic names in a separate file “libraries.gradle”, and in my root project I include it like this:

subprojects { subProject ->
    apply from: '../libraries.gradle'
         apply plugin: 'java'
(...)

The “libraries.gradle” has definitions like these:

ext.log4jVersion
= '1.2.17'
  ext.libraries = [
 commons_collections
       : 'commons-collections:commons-collections:3.2.1',
  commons_io
 : 'commons-io:commons-io:2.2',
 commons_lang2
 : 'org.apache.commons:commons-lang:2.6',
       log4j
   : "log4j:log4j:${log4jVersion}",
(....)

And dependencies of a project are declared like this (this is from the root project within the subprojects clause :

dependencies {
 compile (libraries.commons_lang)
       compile (libraries.log4j)
 (..)
       }

Gradle 1.4 obviously has a problem with my structure. On evaluation phase of the projects, it soon reports errors:

Evaluating project ':bghw_fav_jadice_server' using build file 'Q:\sources\trunk_clf\bghw_fav_jadice_server\build.gradle'
Evaluating project ':bghw_fav_server' using build file 'Q:\sources\trunk_clf\bghw_fav_server\build.gradle'.
Evaluating project ':bghw_fav_server_core' using build file 'Q:\sources\trunk_clf\bghw_fav_server_core\build.gradle'.
Evaluating project ':bghw_fav_servermethods' using build file 'Q:\sources\trunk_clf\bghw_fav_servermethods\build.gradle'
  FAILURE: Build failed with an exception.
  * Where:
Build file 'Q:\sources\trunk_clf\bghw_fav_servermethods\build.gradle' line: 28
  * What went wrong:
A problem occurred evaluating project ':bghw_fav_servermethods'.
> Could not resolve all dependencies for configuration ':bghw_fav_servermethods:compile'.
   > Could not find org.apache.commons:commons-lang3:3.1.
     Required by:
         de.uvdms:bghw_fav_servermethods:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:com.tsystems.favbg.common:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:de.uvdms.bof:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:bghw_fav_server_core:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:bghw_fav_server:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:bghw_fav_server_core:1.0 > de.uvdms:de.uvdms.util:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:bghw_fav_server_core:1.0 > de.uvdms:de.uvdms.common:1.0
         de.uvdms:bghw_fav_servermethods:1.0 > de.uvdms:bghw_fav_server_core:1.0 > de.uvdms:de.uvdms.bof.common:1.0
   > Could not find log4j:log4j:1.2.17.
     Required by:
         de.uvdms:bghw_fav_servermethods:1.0
        (...)

This is somewhat curious, when the the first two projects evaluated ok, but on the third project Gradle reports the error. Curious, because I included the dependency on log4j in the root project definition as a dependency all projects need. So do the first two projects listed above in the info report. And another curiosity is the reported “line 28”: because line 28 is in the middle of a tar task definition where I have:

(...)
       into ('lib') {
   from jar.archivePath
  from configurations.compile.resolve()
 }

Any idea what changed in Gradle 1.4 that conflicts with my current solution?


(Peter Niederwieser) #2

I’m not sure why you are hitting these problems after switching to 1.4. In any case, resolving in the configuration phase should be avoided whenever possible, as it will then happen for each and every build, no matter which tasks get invoked. In the concrete case, you should remove the ‘.resolve()’ in the ‘Tar’ task definition. Other things to try:

  • Perform a clean build (required every time you build with a different Gradle version) * Delete ‘.gradle’ directories * Delete or rename ‘~/.gradle’ (i.e. empty the dependency cache)

PS: It’s good enough to apply ‘libraries.gradle’ to the root project, as subprojects automatically see properties of their parent projects.


(Carlo Luib-Finetti) #3

Hi Peter,

thanks for your tips. I threw away all

In fact , this “resolve” method call was the bad guy when Gradle tried the evaluation of my projects (calling the clean task).

Ok, next. Now, evaluation phase passes over my projects, but compile does not work, as doesn’t search of dependencies, i.e.

Q:\sources\trunk_clf>gradle :de.uvdms.util:depend --configuration compile
:de.uvdms.util:dependencies
  ------------------------------------------------------------
Project :de.uvdms.util
------------------------------------------------------------
  compile - Classpath for compiling the main sources.
+--- org.apache.commons:commons-lang3:3.1 FAILED
+--- log4j:log4j:1.2.17 FAILED
+--- commons-io:commons-io:2.2 FAILED
+--- org.aspectj:aspectjrt:1.6.8 FAILED
+--- javax.servlet:servlet-api:2.4 FAILED
\--- org.springframework:spring:2.5.6 FAILED

Gradle seems to have problems with Maven repository definitions, no?

repositories {
  mavenLocal()
      maven {
       url "http://...."
    credentials {
      username '....'
      password
'....'
    }
  }
   mavenCentral()
}

I tried to comment out each of the defined maven repositories - it doesn’t matter: Gradle cannot find any 3rd party jars. Even just letting mavenCentral standalone does not resolve the dependencies.


(Carlo Luib-Finetti) #4

I did another try by deleting all Gradle folders from my home directory (“C:\Users\cluib.gradle”).

Then another “clean” and another “depend” / “compile”: did’nt change the situation. I’m helpless.


(Peter Niederwieser) #5

Gradle seems to have problems with Maven repository definitions, no?

No such problems are known.

Have you checked the debug log (’-d’)? Could it be a proxy related issue?


(Carlo Luib-Finetti) #6

Hi Peter, this debug output gave me the hint:

12:17:59.642 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.UserResolverChain] Attempting to resolve module 'log4j#log4j;1.2.17' using repositories []

which I do interprete as: there are no known repositories!

In my root project I had the repositories configuration on global scope, but also had an allprojects configuration, saying "apply plugin: java’. Now, I just tried with moving the repositories configuration within this allprojects definition - and now the Maven based 3rd party jars are not missing anymore!!!


(Peter Niederwieser) #7

Repository declaration are (and always have been) per project. It’s hard to imagine that declaring them only for the root project worked in 1.3. Anyway, I’m glad that this solved the problem. Probably Gradle should give a clearer error message when dependency resolution fails and no repositories have been declared.


(Carlo Luib-Finetti) #8

Anyway, now it works again (as it did since 1.0). And sure it would be a good idea to report empty repositories. Thank you so far.