Project Dependency not being honored

Gradle Version: 3.1
Operating System and JVM version: Windows 8.1 6.3 amd64 JDK 1.8.0_65
Is this a regression? No

We have a multi-project build with a intra-project dependencies between the ‘included’ projects. There are a number of interdependencies between the various projects expressed as project dependencies included in the moderately
sized list of the project’s dependencies. While this approach works fine in several other multi-project builds, in this case, the project dependencies are not being honored, therefore sub projects are being built in the wrong order and the build fails.

So, for starters, how do we diagnose what’s going on here in order to determine if it is a bug?

Can you check gradle dependencies to see if the project’s are listed as dependencies as expected? If you can create a build-scan, that would create a report like gradle dependencies and you could share it here.

My guesses would be either

  1. the build adds project dependencies during execution, or
  2. the build has missing dependency information on a particular configuration (that has project dependencies) for the failing task.

If the dependencies report does not show the project dependencies, it’s likely 1).

If the dependencies report does show the project dependencies, it’s likely 2). This is easy to do if you have a custom task that uses a configuration but it doesn’t have a dependency on it.

So the cause appears to be the following:

configurations.all {

resolutionStrategy.eachDependency { DependencyResolveDetails details →

		if (project.hasProperty('xxxPlatformVersion')  &&  project.getProperty('xxxPlatformVersion') != -1) {
        	if( xxxCommonVars.containsKey(details.requested.name) && 
        		details.requested.group =="com.xxx.xx.xx"){
        			details.useVersion(project.getProperty('xxxPlatformVersion'))
        	}

  	}

}

If the dependency in question is a project dependency, setting useVersion causes Gradle to no longer consider it as a project dependency so the ordering is lost. In thinking about it, this is probably the right behavior.