fix: #860 composite gradle build

[ervinpm]

nedtwigg edit: fixes #860

[nedtwigg]

Great PR! I think the System.identityHashCode stuff should only be used for composite builds, which you can detect with project.gradle.includedBuilds.

If you make that change, then the tests should pass again. If they're still failing, you might need to tweak this:

spotless/plugin-gradle/src/test/java/com/diffplug/gradle/spotless/GradleIntegrationHarness.java

Lines 149 to 159 in 93c80ac

	protected static List<String> outcomes(BuildResult build, TaskOutcome outcome) {
	return build.taskPaths(outcome).stream()
	.filter(s -> !s.equals(":spotlessInternalRegisterDependencies"))
	.collect(Collectors.toList());
	}
	protected static List<BuildTask> outcomes(BuildResult build) {
	return build.getTasks().stream()
	.filter(t -> !t.getPath().equals(":spotlessInternalRegisterDependencies"))
	.collect(Collectors.toList());
	}

[ervinpm]

the project.gradle.includeBuilds did not work, it yield 0 in size for the composite projects. I used project.subprojects instead.

[nedtwigg]

I used project.subprojects instead

Hrm... A multiproject build with no included builds should not be doing the hashCode thing. I'd be very surprised if getIncludedBuilds was broken. Can you share any info about your integration test which indicates that getIncludedBuilds is broken?

[ervinpm]

Sure! I added some log lines when testing this:

System.out.println("project name: " + project.getName());
System.out.println("project builds: " + project.getGradle().getIncludedBuilds().size());
System.out.println("project root project: " + project.getRootProject().getName());
System.out.println("project root project builds: " + project.getRootProject().getGradle().getIncludedBuilds().size());
System.out.println("project root project subprojects: " + project.getRootProject().getSubprojects().size());

I have 11 projects under my root project and they are defined in settings.gradle of the root project:

include "project1", "project2", "project3", "project4", "project5", "project6", "project7", "project8", "project9", "project10", "project11"

I have spotless plugin defined in project1 and 2. This is what shows up when I do a gradle build in the root project

$./gradlew build

> Configure project :project1
project name: project1
project builds: 0
project root project: myrootproject
project root project builds: 0
project root project subprojects: 11
Including axis libraries in the build...
classpath
classpath

> Configure project :project2
project name: project2
project builds: 0
project root project: myrootproject
project root project builds: 0
project root project subprojects: 11

I hope this helps.

[nedtwigg]

What you described above is a multi-project build. A composite build is a bit different, you'd have to use includeBuild in the settings.gradle, or else you can specify --include-build on the command line.

Spotless already works 100% with multiproject builds to my knowledge (I am using it on several such projects). I see from #860 that you are in fact getting the is not a subclass of the given type error, which I had previously believed to only be possible with a true composite build, not a multiproject build.

How are you applying spotless? From the settings.gradle? A plugins block in the root build.gradle? Maybe a multiple plugins blocks spread out across multiple subprojects?

[ervinpm]

Oh ok, hopefully this fixes that too. Each subproject has a plugin block with spotless in it, no plugin block in the root project or in settings.gradle. Let me know if you want me to try a specific configuration.

[nedtwigg]

Each subproject has a plugin block with spotless in it

Ahhhh... Interesting. If you specified spotless in the pluginManagement block, I'm pretty sure that would be a workaround for you. I also think it would be a bit faster - sharing a single classloader across projects will help with JIT warmup which is a real factor for Spotless' performance.

The System.identityHashCode trick is kinda nasty. Composite build is a special case, so I was okay adding complexity for a complex case. Multiproject build is very common, I don't like adding this complexity to every multiproject build. But your usage is totally valid.

What do you think about trying this?

try {
  // register buildService or registerDependenciesTask
} catch (InvalidUserDataException e) {
  if (e.message.contains("is not a subclass of the given type")) {
      // try again with the System.identityHashCode trick
  }
}

That way the workaround only happens when absolutely needed, and the rest of the time users get nice predictable and repeatable task names.

[ervinpm]

Thanks for that tip on plugin management, that did work, I was traveling and did not get the chance to come back to this.

[nedtwigg]

Published in 6.0.4.