Plugin breaks aar module

When ktlint plugin is applied to a module that just holds AAR artifact (via allprojects block), it appears to break that module’s output - build complains about classes from that module missing.

Steps to reproduce:

1. Download and assemble KtlintAar.zip
2. Note that build will fail
3. Go to root build.gradle and comment out apply plugin line for ktlint
4. Assemble again
5. Build will work

[tbroyer]

Let’s look at it the other way around: is there any reason for the ktlint configuration to be consumable by other projects? The KtLint plugin will resolve it in the same project, but will never need to consume it from another project. IMO the configuration should be isCanBeConsumed = false and isVisible = false.

Here’s a small reproducer:

// settings.gradle.kts
include("producer", "consumer")

// producer/build.gradle.kts
plugins {
  id("org.jlleitschuh.gradle.ktlint") version "10.1.0"
}
configurations.create("default")
artifacts.add("default", buildFile)

// consumer/build.gradle.kts
plugins {
  `java-library`
}
dependencies {
  implementation(project(":consumer"))
}

Now run gradle :consumer:dependencies and/or gradle :consumer:dependencyInsight --configuration compileClasspath --dependency producer. You can also start poking around: comment out the KtLint plugin, add the java-base plugin rather than creating the default configuration manually, add the java plugin, add an attribute to the default configuration (any attribute that’s requested by consumer, as shown by dependencyInsight), etc. Depending on the changes, you’ll either see the variant switch from ktlint to default or an error because Gradle cannot determine which variant to use. Notice how the behavior changes depending on the attribute(s) you add to the default configuration.

What seems to happen here is that the default configuration above is created without attribute, so when the project is consumed from the other project, Gradle has to decide between a variant without attribute and another with one matching/compatible attribute (ktlint), so it chooses the latter. When you change the default configuration to add one matching attribute, Gradle cannot decide and the build fails. If you add the bundling attribute and another matching attribute, Gradle will prefer the default configuration over the ktlint one. When you use a previous version of the KtLint plugin, that didn’t declare any attribute on the ktlint configuration, then Gradle chooses the default configuration because it cannot use variant-aware resolution at all. The addition of the attribute on the ktlint configuration that is consumable broke the projects because then it “enabled” variant-aware resolution, and ktlint is a valid variant for the project.

You could argue that the producer project should declare attributes on its default configuration, but I’d say the ktlint configuration has no reason to be consumable to begin with.

I tested, and adding:

isCanBeResolved = true
isCanBeConsumed = false
isVisible = false

to the ktlint configuration fixes the problem. Ideally, this should be added to all the KtLint-related configurations, as there’s no reason that the ruleset, baseline, and reporters be consumable as well. (I explicitly set isCanBeResolved = true despite that being the default value, for exhaustiveness and explicitness)

[JLLeitschuh]

Excelent description!