Closed kuniss closed 1 month ago
159 tests - 6 159 :white_check_mark: - 6 0s :stopwatch: ±0s 22 suites - 1 0 :zzz: ±0 22 files - 1 0 :x: ±0
Results for commit 24aea5a3. ± Comparison against base commit 72ee439e.
:recycle: This comment has been updated with latest results.
@mjpcger, do you want to review this pull request before I'm merging it? Most of the work is from your contribution...
I would, however, publish a pre-release of the original branch to Maven Central such that it can be verified in local build environments.
@mjpcger could you please make a final review and approve the PR, please? You should have something like the following in the GitHub GUI under the Review Changes button:
I could merge without your approval (because I'm the project admin 😄), however, I would like to try the "clean" process way... Thanks!
A RC built from this PR has been published to Maven Central's snapshot repository at https://oss.sonatype.org/content/repositories/snapshots/org/javapos/javapos-config-loader/4.0.0-SNAPSHOT/.
It may be downloaded from there or resolved by dependency resolution if configured appropriately, e.g. for Gradle:
repositories {
maven {
url 'https://oss.sonatype.org/content/repositories/snapshots'
}
}
dependencies {
implementation 'org.javapos:javapos-config-loader:4.0.0+'
}
Who ever is interested, please integrate in your environment for testing purposes and report back any issue here in this PR.
More approval is not possible for me. Looks as if I have no write access and therefore my approval is not enough to change the Review required status.
Thanks, @mjpcger! I adjusted the branch rules. Now I can merge according to the rules. 😄
Who ever is interested: We just encountered in our off-side integration test that some of our JavaPOS XML configuration files are not read in correctly by the new javapos-config-loader-4.0.0-RC1, Those were read in without errors by the Xerces implementation, however.
We are investigating...
The reported regression was a misinterpretation. In fact, it new XML populator is just more accurate. If the DTD is given in the JavaPOS XML configuration file like ´´´ <!DOCTYPE JposEntries PUBLIC "-//JavaPOS//DTD//EN" "jpos/res/jcl.dtd"> ´´´ then file jpos/res/jcl.dtd must be in the classpath, otherwise the validation fails and no entries are read in.
I improved the tracing a bit. So, I'm going to publish a new SNAPSHOT on Maven Central's snapshot repository - RC2.
This PR is intended to implement the new major version 4 of javapos-config-loader incorporating the following major changes