Support #5581
closedName of the jar file xmlresolver-4.2.0-data.jar not aligned with documentation
0%
Description
When upgrading Saxon-EE 10.8 to 11.3 we need xmlresolverdata-4.2.0.jar (in addition to xmlresolver-4.2.0.jar) when validating files with an xsd that imports svg.xsd or xlink.xsd. We notice that the name of the jar file xmlresolver-4.2.0-data.jar in SaxonEE11-3J.zip is not aligned with the documentation which follows the more common convention with the version number at the end: xmlresolverdata-4.2.0.jar .
Updated by Norm Tovey-Walsh almost 2 years ago
Hi,
Thanks for the observation. When the “data” jar was created, I tried to
work out how classifiers were represented in filenames. I came to the
conclusion that the format was “name-version-classifier”. If I’m
mistaken, I’ll switch to “name-classifier-version” for the next release.
Be seeing you,
norm
--
Norman Tovey-Walsh ndw@nwalsh.com
https://nwalsh.com/
5% of the world's population consumes a third of its resources and
makes nearly half its waste. That 5% is US.
Updated by Johan Gheys almost 2 years ago
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.
Updated by Norm Tovey-Walsh almost 2 years ago
Saxonica Developer Community notifications@plan.io writes:
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.
Right. I’ll try to get that sorted out before the next release.
Be seeing you,
norm
--
Norman Tovey-Walsh ndw@nwalsh.com
https://nwalsh.com/
Happiness is nothing more than good health and a bad memory.--Albert
Schweitzer
Updated by Johan Gheys almost 2 years ago
Ok, perfect, thanks for the willingness
Updated by Norm Tovey-Walsh almost 2 years ago
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?
Updated by Johan Gheys almost 2 years ago
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.
Updated by Norm Tovey-Walsh almost 2 years ago
- Status changed from New to Resolved
Documentation updated. Apologies for not seeing that more quickly!
Updated by Johan Gheys almost 2 years ago
No problem and thanks for the alignment.
Updated by O'Neil Delpratt about 1 year ago
- Status changed from Resolved to Closed
Please register to edit this issue