Does anyone know whether it is intended that a version constraint influences the classpath order? To me this comes unexpected. If you have

dependencies {
    runtimeOnly("saxon:saxon:6.5.3")
    implementation("net.sourceforge.nekohtml:nekohtml:1.9.22")
}

and do

System.out.println(SAXParserFactory.newInstance().newSAXParser());

You get Aelfred which is shipped with Saxon 6. But if you do

dependencies {
    constraints {
        implementation("xerces:xercesImpl:2.12.2")
    }
    runtimeOnly("saxon:saxon:6.5.3")
    implementation("net.sourceforge.nekohtml:nekohtml:1.9.22")
}

you "suddenly" get Xerces. Actually using

val foo by tasks.registering {
    doLast {
        configurations.runtimeClasspath.get().forEach { println(it) }
    }
}

to output the runtime classpath also shows that the order is not in declaration order anyway. Without the constraint you first have neko, then saxon, then the neko dependency xerces, then the xerces dependency xml-apis. With the constraint you first have neko, then xerces, then saxon, then xml-apis.

It is I believe, because internally in the engine the constraints work very similar to dependencies. (only that they are skipped if not applicable) That's why ideally you should not rely on classpath order 😬 If you need to have a certain order because you can't solve it differently (by excluding dependencies or other means), I think it's best to sort the classpath yourself in a

doFirst

– which is still hacky but the best solution I know of. Have done that multiple times for test classpaths where getting things into the right order was the only solution.

Yeah, class path order relying is of course bad, but sometimes we have not much choice and manual sorting is also not always possible. In this case the alternative would probably be an artifact transform that removes the service description from the Saxon 6 dependency, but now tell me that is not hacky. :-D I need the Xerxes parser for parsing, I need Saxon 6 for docbook xsl 1 processing. Saxon has Aelfred parser shipped in the same jar. Manual ordering is not possible as it is in

buildSrc

dependencies. Setting system property in

gradle.properties

is also not possible as then the settings script fails as it also parses an XML file and there the built-in parser is used. In the end I just moved the dependencies around so that the resulting order works as I need it in this case.