java.lang.SecurityException: class "org.eclipse.jface.text.ITextHover"'s signer information does not match signer information of other classes in the same package

[ewillink]

Version: 2024-09 (4.33) Build id: I20240903-0240

225 again

org.eclipse.jface.text.ITextHover comes from org.eclipse.jface.text (3.25.200.v20240816-1151) "JFace Text"

org.eclipse.jface.text.Document comes from org.eclipse.text (3.14.100.v20240524-2010) "Text"

and these have different signer

Whatever, this is at least the fourth time that I have been burned by inconsistent platform fragment builds. Long overdue for the promised fix (or at least a release test to force a re-spin).

cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=573306 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536445 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=534938 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=510663 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=466677 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=466364 cf: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408901 ....

[merks]

Also reported here

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2335

now there are tests that run daily to prevent future recurrence.

[ewillink]

Fantastic that there is a fix going forward. But 4.33 is broken. Are there plans for a 4.33a?

[merks]

No, unfortunately not.

[ewillink]

But 4.33 is a bad build.

[merks]

It’s not the first time a release shipped with such a problem but hopefully the last time.