eclipse / xtext

Eclipse Xtext™ is a language development framework
http://www.eclipse.org/Xtext
Eclipse Public License 2.0
767 stars 320 forks source link

Xtext Web API tests fail #3216

Open LorenzoBettini opened 11 hours ago

LorenzoBettini commented 11 hours ago
java.lang.SecurityException: class "org.eclipse.core.runtime.OperationCanceledException"'s signer information does not match signer information of other classes in the same package

This started to happen after merging https://github.com/eclipse/xtext/pull/3214 but the PR was building successfully so something must have changed in the meantime in platform?

cdietrich commented 11 hours ago

This seems inconsistent version of core runtime and equinox common

cdietrich commented 11 hours ago

Is this on the old tp or latest

LorenzoBettini commented 11 hours ago

latest TP.

The PR built fine, but main doesn't. Something has changed in the eclipse repos.

cdietrich commented 11 hours ago

Maybe they changed the cersts but not consistent for both?

cdietrich commented 11 hours ago

Unfortunately inspection of jar files does not work on phone so I cannot check

LorenzoBettini commented 10 hours ago

xtext.web is a Maven project, not PDE, so maybe there's a mismatch with Maven deps and Tycho deps. Maybe I can check that tomorrow

LorenzoBettini commented 10 hours ago

This could be the culprit:

https://github.com/eclipse/xtext/commit/554c1c737ec65f12a21c7c6d9c508c54384dc28f#diff-b0062f4550d17821c54c936950b8d82bcd292353af967eb70f3bc26991b1b1e0

The commit message says, "explicitely consume core.runtime to prefer maven deps over p2," but if we add such a dep in the POM to be sure it takes a specific version, we should also pin the other eclipse deps like equinox common, to avoid conflicts with the PDE TP. At least, that could be the cause.

cdietrich commented 10 hours ago

Maybe we need to add equinox common there too But why would the p2 one win now

LorenzoBettini commented 9 hours ago

I did a few experiments locally, where I reproduced the problem:

<dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.core.runtime</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.equinox.common</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.osgi</artifactId>
    <scope>test</scope>
</dependency>

shows a compilation error in Eclipse

"The import org.eclipse.core cannot be resolved"

without osgi

"The type org.eclipse.core.runtime.IProgressMonitor cannot be resolved. It is indirectly referenced from required type org.eclipse.xtext.findReferences.IReferenceFinder"

indeed, equinox common is a compile dependency of xtext. core.runtime depends on equinox.common so making core.runtime a test dependency somehow breaks the compilation in Eclipse, which makes sense.

LorenzoBettini commented 8 hours ago

At least, instead of running the Maven build, the problem can be reproduced also from Eclipse, running /org.eclipse.xtext.web/xtext.web.tests.launch

LorenzoBettini commented 8 hours ago

This seems to do the trick: https://github.com/LorenzoBettini/xtext/commit/2df1f08df7e76707fac9be7a6c82f9e9f082c1a6

IMPORTANT: the order is important and note the scope compile.

I'll check whether we can go back to test scope

LorenzoBettini commented 8 hours ago

No need to pin all those deps: it's enough to pin core.runtime as test dependency but BEFORE the other dependencies.

On a side note, in the TP I see org.eclipse.core.runtime_3.32.0.v20241003-0436.jar so it has indeed been released after the PR, which was built fine, was merged.