Some XSpec for testing CI/CD #9
Conversation
|
Still working on this - next step is to get some iXML into the XSpec and see how we can run that. Ant configuration of XSLT extension support for iXML requires the following, which might be pertinent for XSpec running in Saxon under Maven:
|
…rted under CI/CD)
|
As expected, the check fails. But the traceback doesn't really show the cause -- presumably because the XSpec added to the commit won't compile and run due to its iXML dependency. Solutions? - find a way to configure Saxon inside the Maven/Xproc configuration - or, run the CI/CD using Ant instead of XProc? which could potentially be configured with the necessary |
…g NineML extension library support in XSLT under XProc
|
See when we exclude the XSpec from the test run as in the last commit, everything passes. Reproduce the error by commenting out line 96 of the POM.xml (the exclusion rule). 540ae10#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R96 |
|
Next on this work item:
Rationale for all this? See wendellpiez/oscal-xslt#2 |
…cquisition script
|
This PR has grown considerably since its start as a small test. @aj-stein-nist, @nikitawootten-nist, @galtm, and friendly readers, I would very much appreciate any tire kicking of the xspec support now included herein (hopefully familiar from the repo it is migrated from). This repo's CI/CD configuration remains the Maven XSpec set up in the top-level There is also a pom.xml now in These could be consolidated; indeed the new scripts could be used under CI/CD as they are in metaschema-xslt. But this might be good to go for now. Advice, concerns, observations? |
common/pom.xml
Outdated
| <modelVersion>4.0.0</modelVersion> | ||
|
|
||
| <groupId>gov.nist.secauto.oscal.tools.core</groupId> | ||
| <artifactId>metaschema-processing-support</artifactId> |
There was a problem hiding this comment.
Is it OK that this refers to metaschema even as it moves to this repo?
|
@galtm I think I've addressed all the comments above making many improvements thanks! |
README.md
Outdated
|
|
||
| - `.github` - for Github CI/CD | ||
| - `common` - holds common `bash` scripting - utilities for reuse | ||
| - `support` - contains submodules, dynamic resources and libraries (or scripts for downloading them), also [XSpec support in development](support/xspec-dev/), |
There was a problem hiding this comment.
support should now say lib, unless support/ will still exist for other things. And "XSpec support in development" is at the top level now, isn't it?
|
To wrap this up:
Assuming this sounds okay for now, only some docs/enhancement remains for this PR. Finally, going forward |
Yes, yes, please. |
…orks better cross-platform)
| "recurse=yes" \ | ||
| "theme=toybox" | ||
|
|
||
| mvn --quiet \ |
There was a problem hiding this comment.
I really like this change. I was able to run the tests via this makefile from a "Git Bash for Windows" window, without having Linux or WSL installed. Before this change, that didn't work for me.
There was a problem hiding this comment.
Interesting, I am really curious as to how this change made it work. I guess I have to test on Windows.
There was a problem hiding this comment.
It's actually not the change shown, but this change: 5175b3b
PR revised
This PR now holds an entire XSpec support infrastructure, not just some XSpec testing.
The intent is that repositories that include this one as a submodule should get XSpec support along with it.
PR original description
The XSpec is a very basic standalone, small but real-worldish.
PR #8 is related but the files here are all in the
directory-manifest(application) directory, as a typical example.In the short to medium term we cannot hope to have XSpecs for everything (can we?), but we can at least show how it can be done.