(sorry...) ... the original intent and design of XALAN-TEST is to be a general XSLT standards compliance suite as much as (or more than) tests for the Xalan-J implementation alone. As such, it was a semi-independent project that could be, and was, configured to validate other implementations too. It could be run against Xakan-C with a bit of bridge code, and if I remember correctly even SAXON was testing against it at one point. Yes, some of it is specific to Xalan-J, but most of it -- especially after the adoption of TrAX and JAXP as the javax API -- is not.
That doesn't mean we can't bundle it into Xalan and tell folks to fetch Xalan to get a copy of XALAN-TEST; that would be less convenient for its other users but perhaps more convenient for us, especially with the shelving of Xalan-C. On the other hand it means that any unit tests (which we really don't have yet) would want to be kept separate from this compliance suite, and invokes separately, so it isn't clear that folding it into the main is actually the optimal solution. We want to rest against it, it wants to test against us, we own both, but they aren't necessarily one thing; the separation has meaning, though one can argue that the meaning is obsolete. Also, of course, I agree that we SHOULD be looking to reduce the embedded binaries in xalan-test, as I have been doing for Xalan-J. But that doesn't need to happen concurrently with this major change to Xalan-J build; it's a separate task. And should have its own Jira item. I haven't checked whether one already exists; feel free to create it you get to that before I do. But reducing the binaries in its git repository is a separate task from deciding whether to fold it into Xalan-J, and doesn't have to wait for the latter. And I don't think either is at the top of my own priority list right now. I want to get off build for a while. So: Valid points, not blockers to current work, design decisions needed, priority open to discussion, awaiting volunteer to drive them. Should be added to backlog if not already there, probably as two issues rather than one. Or that's how I read it, anyway. There's no shortage of work that should, or SHOULD, be done. -- /_ 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. ________________________________ From: Vladimir Sitnikov <[email protected]> Sent: Saturday, December 30, 2023 2:01:02 AM To: [email protected] <[email protected]> Subject: Re: Policy question re src distribution >In the past, the src tarball/zipfile has included an embedded copy of >xalan-test Please review the release policy https://www.apache.org/legal/release-policy.html#source-packages In particular, they say "A source release SHOULD not contain compiled code". As xalan-test contains many jars with compiled code, you should rather NOT include xalan-test in its current shape into xalan-java source packages. At the same time, they say "Each PMC MUST obey the ASF requirements on approving any release." >Or should xalan-test have its own distros? That would be overhead without much benefit. It would be better to integrate tests into xalan-java code eventually. Vladimir
