1) Maven build of xalan does not currently fold xalan-test into the source distribution zipfiles/tarballs. This could presumably be added to the "distribution" sub-module, by having it perform the check-out and by updating the src.xml to include the resulting subdirectory. We might want to do that anyway. Or might not.
2) The documentation should be reviewed to make sure all references to file locations are correct, that sample package name references are correct (they used to be in the default java package, ie none), that the samples still work (I haven't tested very seriously, since honestly most of those samples are not very informative or current) and that the website will properly reflect these changes after being updated.
3) At some point we need to consider at least basic tests for the samples.4) Gary: Part of the reason you wanted us to move to Maven was that there were a number of code-quality plugins you wanted to apply. I think it's time for you (and possibly others) to start working on that...
5) Xalan-test should have its paths reworked to avoid dependency on unversioned versioned names for dependencies. The simplest fix may be to use the one form of wildcard permitted in classpaths, sourceDirectory/* (include all jarfiles in that directory), which avoids the filename issue entirely. Alternative is to make versions explicit, and update them as Xalan's version and dependency versions change. (Current kluge, for back-compatibility with the Ant build of Xalan, is to put both versionless and explicitly versioned jarfile names on the paths.)
5a) Once that's resolved, we can change the xalan-j build to not produce the unversioned names in the build/ directory -- and probably then switch to depending directly on the jarfiles which land in target/.6) Xalan-test should have its dependency on manipulating bootClassPath and/or "endorsed" libraries removed. In theory, it should now to be possible to make sure the "real" Apache version of the code is invoked by setting the appropriate parameters for the javax/JAXP factories, plus the equivalent for serializer (which apparently got left out of that standard, sigh), eliminating the need to cheat our factories onto the front of the classpath. We should also add that solution to our documentation, since javax will otherwise default to whatever is being shipped as com.sun.org.apache.local.xalan etc.
7) We need to clearly divide xalan-test into the part which is intended to be a general XSLT Recommendation (plus standardized extensions) conformance suite applicable to any processor which implements the JAXP/javax/DOM/SAX interfaces (or can be front-ended with an adapter which speaks that interface, for non-Java implementations), and the part which is specifically testing Xalan-J features. The latter, arguably, should be moved into the Xalan-J project even if xalan-test remains a separate tool.
7a) NOTE that as part of this we should consider whether there are better XSLT conformance suites now available; if someone else is doing that work we might want to put most of xalan-test into the attic and leverage/support that instead, making sure that it covers all the edge cases xalan-test examined. (I'm less concerned with Apache having an independent open version of the tests than with it having an independent open XSLT engine.) By now it's possible that W3C itself has a Recommended conformance suite.8) When we've fixed things our practice has been to add tests to the conformance suite which distinguish the old and new behaviors. We should continue doing that.
But, as folks have pointed out, we really don't have unit tests for any of this code below that conformance level. Creating them would be a MAJOR effort, but might flush out some lurking horrors or motivate creating cleaner interfaces/signatures... and would be a real deep-dive education in how this system works, if someone wanted to go that far.
Meanwhile, it might be good practice to consider creating/updating a unit test any time we are changing a class. Still a lot of additional work unless the class already has such a test, but at least that breaks it up into bite-sized chunks and would get us started. Downside is that initially creating a worthwhile unit test may be as much work as applying the fix to Xalan itself, and requires dealing with junit/mockito/spock/whatever. (I don't have strong opinions on which frameworks may be better than others -- or indeed on whether all tests need to be written against the same framework. Spock interests me because it appears better integrated than most -- mocking built in -- and because it permits representing input/output combinations as "truth tables" which I've always felt was a particularly clear and easy-to-read way of describing expected behaviors.)
The test for the new Version code can serve as a template for how to plug unit tests into the Maven build system.
-- ` /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. Feel free to call him on it.
OpenPGP_0xFFBAFF963D937815.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
