Saxon

For us, it is a jar file like any other that we load via a maven dependency. Therefore, we use the filename of the documentation internally. It would just be convenient if we didn't have to do the rename in the future.

Ok, perfect, thanks for the willingness

Either this is a case of conflicting expectations, or there's something else going on that I don't undertand. I went back to see if I could resolve why the name was not consistent with common practice. What I discovered is that I'm using this task:

task dataJar(type: Jar, dependsOn: ["copyData"]) {
  archiveBaseName = "${basename}-${resolverVersion}"
  classifier = 'data'
  from "${buildDir}/data"
  manifest {
    attributes "Built-By": "Norman Walsh"
    attributes "Implementation-Vendor": "Norman Walsh"
    attributes "Implementation-Title": "XML Resolver data"
    attributes "Implementation-Version": resolverVersion
    attributes "Automatic-Module-Name": "org.xmlresolver.xmlresolver_data"
  }
}

Note that I'm not explicitly locating the classifier in the jar filename. When I lookup the Jar task in the Gradle documentation, I find:

If the name has not been explicitly set, the pattern for the name is:

[archiveBaseName]-[archiveAppendix]-[archiveVersion]-[archiveClassifier].[archiveExtension]

That suggests to me that (at least in the Gradle community) the expectation is that the classifier comes after the version.

Do you recall where you found the "version comes last" convention?

We load the jar file via a maven dependency and follow the maven convention of groupId, artifactId and version. The easiest way for us is to rename xmlresolver-4.2.0-data.jar to xmlresolverdata-4.2.0.jar as mentioned in the documentation. But if this causes problems on your side, you may as well change the documentation.

No problem and thanks for the alignment.