Project

Profile

Help

Support #5581

closed

Name of the jar file xmlresolver-4.2.0-data.jar not aligned with documentation

Added by Johan Gheys almost 2 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Low
Category:
-
Sprint/Milestone:
-
Start date:
2022-06-24
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
11
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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 .

Actions #1

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
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.

Actions #2

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.

Actions #3

Updated by Norm Tovey-Walsh almost 2 years ago

Saxonica Developer Community 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
https://nwalsh.com/

Happiness is nothing more than good health and a bad memory.--Albert
Schweitzer

Actions #4

Updated by Johan Gheys almost 2 years ago

Ok, perfect, thanks for the willingness

Actions #5

Updated by Michael Kay almost 2 years ago

  • Assignee set to Norm Tovey-Walsh
Actions #6

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?

Actions #7

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.

Actions #8

Updated by Norm Tovey-Walsh almost 2 years ago

  • Status changed from New to Resolved

Documentation updated. Apologies for not seeing that more quickly!

Actions #9

Updated by Johan Gheys almost 2 years ago

No problem and thanks for the alignment.

Actions #10

Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF