See the rest of my response. Xalan-test inclusion in xalan-source was a courtesy to the folks fetching that package, permitting functional verification of a correct build. I actually agree with you that such isn't absolutely necessary, which is why I suggested dropping that and telling folks to fetch it separately if desired. That *would* be a change from past builds. Maybe desirable, maybe not, which is why I raised the question here. But it isn't a foregone conclusion that it should (lowercase) or should not happen now.
I lean slightly in favor, for reasons discussed. But only slightly. Similarly, I'm in favor of cleaning it. But I, myself, do not consider that a high priority at this time. If someone feels strongly enough about these points to make them happen sooner rather than later, within the ground rules I mentioned -- or wants to argue that we should change those ground rules, especially if there is another conformance suite our there we should be collaborating with -- that's worth considering. Otherwise: put it on Jira and we will get to it when someone _does_ bring it to the top of the priority queue. Everything can't be top priority at once. Especially with limited resources. Triage is necessary and appropriate. And as a volunteer project we're also gated by enthusiasm. Watchword of open source: if you think a change is essential, and can't wait for it, contribute it or hire someone to contribute it. -- /_ 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