Re: StyleTest.testNewerStylesheet intermittent test failure

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