API for Ordering artifacts collection

[stephanenicolas]

We are working on a problem on Android: removing duplicate resources (described in an xml file) between modules that provide conflicting resources values. In this case, the Android Gradle Plugin will query Gradle to get a list of artifacts that is obtained by linearizing the dependency tree. It does more or less this:

def runtimeConfiguration = project.configurations["debugRuntimeClasspath"]
  def artifactsForAaptMerging = runtimeConfiguration
          .incoming
          .artifactView { view ->
            view.attributes { attributeContainer ->
                attributeContainer.attribute(ARTIFACT_FORMAT, "android-compiled-dependencies-resources")
            }
          }
          .artifacts
          .artifacts

the list of artifacts, though, is ordered in a complex way that goes beyond the predictability power of a human brain: a simple edge change in the graph can totally change the order of the linearization, even between modules that do not conflict. Here is an example: https://github.com/stephanenicolas/Dependency-Resources-Linearization/.

From the Gradle team perspective, the same problem can be applied to dependencies providing conflicting classes and Gradle has to determine which comes first to produce a classpath. It appears that the order would be quite difficult to control in cases where 2 dependencies with the same classes, an unvoluntary change in the dependency graph could swap classes being used at runtime (no, swapping the 2 dependencies isn't the only way to influence the graph, please read the repo's readme above).

There is already an API to control this in Gradle:

gradle/subprojects/core-api/src/main/java/org/gradle/api/artifacts/ResolutionStrategy.java

Line 390 in 8e4f3df

void sortArtifacts(SortOrder sortOrder);

but this API only provides 3 enum values for odering.

Ideally, here we would have an API that lets us specify an ordering freely. In our case, we don't want to provide a complete ordering relation, but a partial ordering. We want to express that dependencyA < dependencyB. It would not be satisfying to provide a comparator.

An efficient implementation of a partial ordering like this could be achieved in O(n) where we would swap unordered dependencies in the linearized DAG. It would give a O(mxn) where m is the number of rules, and n the number of dependencies.

The API could still be provided as a resolution strategy ordering, but maybe as a linear ordering priority pairs list. Ultimately this list could be added to any plugin's DSL when needed.