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]
