This is not a plugin but library, does not need
to be tested against several Maven versions,
just to be built with one.

As iterator may have more, but no file check is done

---

https://issues.apache.org/jira/browse/MRESOLVER-483

Instead to immediately give up and sleep, they will sit a while to enter critical region. This is important for "hot" locks.

Explanation: currently a "loser" will _immediately give up_ and will go to sleep 100ms if cannot enter critical region, even if winner exits critical region within next 5ms. The retry is needed to ensure that it is retried as much as given time/unit takes, that was before consumed by constant retries+sleeps. The logic still works, as if tryLock spends time/unit waiting on criticalRegion (which is possible only on VERY HIGHLY congested locks), there will be no retry happening.

Backport of 089796b

---

https://issues.apache.org/jira/browse/MRESOLVER-522

Changes:
* hazelcast 5.3.7
* redisson 3.28.0
* commons-codec 1.16.1
* sisu 0.9.0.M2
* guice 6.0.0 (and guava 33.1.0)
* jetty 9.4.54 (used in tests)
* maven 3.9.6 (used in demos)

---

https://issues.apache.org/jira/browse/MRESOLVER-527
https://issues.apache.org/jira/browse/MRESOLVER-528
https://issues.apache.org/jira/browse/MRESOLVER-529
https://issues.apache.org/jira/browse/MRESOLVER-530
https://issues.apache.org/jira/browse/MRESOLVER-531
https://issues.apache.org/jira/browse/MRESOLVER-532
https://issues.apache.org/jira/browse/MRESOLVER-533

…469)

This seems more logical step, simply use File.setLastModified
as it does not throws, and is used all over the 1.9.x codebase.

---

https://issues.apache.org/jira/browse/MRESOLVER-536