(sorry again. Phone keyboard.. ) And we would need to handle the distinction between things that we know are working, and things that by design should work, but don't yet, as we have in the test suite.
All of which is doable. None of which is currently at the top of my own priorities. But that refactoring, in specific, is a much more tractable task then restructure and the entire test suite.. so if somebody wanted to tackle that, more power to them. Ditto for getting at least a basic functional test written and integrated. It doesn't have to be a complete test against the standards definition to be useful, though that was the goal of the test project. Basically, a smoke test should probably be part of the package, though a Recommendation conformance suite might not want to be. Real world questions, unfortunately, don't always have cut and dried answers. In theory, practice follows theory. However, in practice,.. -- /_ 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 <sitnikov.vladi...@gmail.com> Sent: Saturday, December 30, 2023 9:03:57 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: Policy question re src distribution >First, remember that SHOULD is not MUST, and that one of the distro files >(bin) is already fully compiled code and carries the binary dependencies to >run it, by design and decades-long history Thank you for the reminder that PMC is free to ignore the rules as they see fit. A decade-long bad practice is not the best excuse for adding more binaries to the mix. A year ago Gary said "migration to Maven would alleviate the binaries-in-source-packages issues", and the suggestion of adding more jars to the source release goes against the rules: https://lists.apache.org/thread/v6sxd9kb3r1m5qq0vv0t6gwg5wg99y9r Since the build system is going to switch anyway, the ones who build xalan-java from the source would have to adapt anyway. There's no point in reproducing decare-old source release packages byte-to-byte. Go ahead and remove the unnecessary stuff. >it wouldn't be impossible, just ugly. I do not see reasons to go for ugly solutions that deviate from the ASF policy. How about just skipping the ugly work and avoiding xalan-test in the xalan source package? The less you have to do the faster you can deliver the first iteration. If somebody wants to execute tests, they can download xalan-test and be done with it. Vladimir
