Hi Jaikiran as far as WHATSNEW is concerned I'm not sure anybody would notice if we changed it. But it wouldn't hurt to make it tell the truth (and remove the mention, yes).
Stefan On 2026-08-09, Jaikiran Pai wrote: > Thank you for these details Stefan. I was considering either updating > this test or removing it this weekend, but haven't been able to get to > it. Looking at the history of that test it didn't look too useful to > retain. I'll try and get to it this coming week. > As for the WHATSNEW text, do you suggest we update it to remove > mention that the older behaviour can be retained through the > granularity attribute? > -Jaikiran > On 01/08/26 1:46 pm, Stefan Bodewig wrote: >> On 2026-07-26, Jaikiran Pai wrote: >>> I went through the history of changes to that task. It looks like we >>> recently changed the code in that task through >>> https://github.com/apache/ant/commit/dc3d7ed34cd506a5b853af5f6dee25ec9ff8a094. >>> As >>> noted in our release notes: >>>> Under certain edge cases this means xslt will now not process files >>>> it would have processed before (when the timestamps of source or >>>> stylesheet are very close or even equal to the timestamp of the >>>> target). In this case you can set granularity to 0 to get back to the >>>> behavior of 1.10.15. >>> As part of that commit the test was (rightly) updated to use a >>> granularity of 0 to retain the previous behaviour. However, it looks >>> like this is not enough to get back the old behaviour. Specifically, >>> in the new behaviour, the "SelectorUtils.isOutOfDate()" has this >>> check: >>> (sourceLastModified - granularity) > targetLastModified) >>> Notice the use of greater than in that check. That differs from what >>> was before the change, which was >>> https://github.com/apache/ant/commit/dc3d7ed34cd506a5b853af5f6dee25ec9ff8a094#diff-ef05d180b6be18199aec5998859d8da5d9dd6f82f6f645883b50f949fde043ae >> Which was changed to use >= a very long time ago >> https://github.com/apache/ant/commit/eb409a2265b661fea9fbf24269b5dc494dc4ef12 >> in order to make the test pass. >>> Notice the use of >= in this check. So even with a granularity of 0, >>> the newer check will not behave like it was previously. >> So WHATSNEW is wrong and there is no way to return to the old behavior. >>> I can't think of a way to address this failure and I wonder if this >>> could impact actual builds, that use "xslt", as well. Any thoughts on >>> what we should do? >> IMHO the behaviour of <xslt> by means of SelectorUtils now is the same >> as for every other task and I'd leave it as it is. As noted in >> https://bz.apache.org/bugzilla/show_bug.cgi?id=65756 this also means >> files specified as resources (the nested style element) now get treated >> the same way as files specified directly - they would have used >> different branches before the change. >> I must admit I've become so used to ignoring the error I really only go >> looking for new errors if more than one build fails in Jenkins. >> I could very well live with removing the test. >> Stefan >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
