FJ: xtext-maven-plugin fails in Xtext 2.27.0

[LorenzoBettini]

investigate

[LorenzoBettini]

For the moment it has been disabled in that project.

[cdietrich]

@LorenzoBettini do you have an error message? can run it with -X

[LorenzoBettini]

@cdietrich tons of errors of the shape

Error:  ERROR:Rule invocation type Class is not subtype of JudgmentDescription declared type EObject (file:/home/runner/work/xsemantics/xsemantics/examples/org.eclipse.xsemantics.example.fj/src/org/eclipse/xsemantics/example/fj/typing/fj-separated.xsemantics line : 170 column : 11)

which typically means that something's wrong with the classpath. That's the only project where it fails, in other example projects the plugin works... maybe something's wrong in the configuration of that project.

[LorenzoBettini]

It also happens in the other DSLs (it only works in the .dsl.tests project)

[cdietrich]

i am not aware if any changes that could have caused this.
@LorenzoBettini tycho and maven versions are kept the same?

[LorenzoBettini]

@cdietrich I've upgraded Tycho to 2.7.3. It was 2.7.0 before I upgraded to Xtext 2.27.0.

In any case, I'll investigate this later.

In the .dsl.tests project, the plugin works perfectly, so I really think it's a problem of some dependencies that are not specified correctly somewhere in Xsemantics.

[cdietrich]

we changed some reexports, but i am not sure if it was in 226 or 227, so maybe some deps can no longer be resolved

[LorenzoBettini]

that's also my feeling.

[LorenzoBettini]

@cdietrich to make things worse, it only fails on the CI (GitHub Actons): it works perfectly on my local machine (even with an empty .m2 folder)... I'll investigate a bit further...

[cdietrich]

Can you try different maven versions , also locally
I had a bug with tycho 3.0 on maven 385 and 386 only recently

[cdietrich]

Can you also check the flag as discussed here eclipse-tycho/tycho#989

[LorenzoBettini]

@cdietrich thanks for the suggestions! I'll try tomorrow.

[LorenzoBettini]

Can you also check the flag as discussed here eclipse/tycho#989

@cdietrich concerning that discussion you mentioned: that is related to eclipse-tycho/tycho#781, which I opened and had already applied <skipPomGeneration>true</skipPomGeneration> some time ago, so that is not the culprit.

[LorenzoBettini]

Can you try different maven versions also locally I had a bug with tycho 3.0 on maven 385 and 386 only recently

@cdietrich Thanks for your suggestion! The problem was found and fixed! :)
It was the Maven version!
According to https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-Readme.md, the Maven version used in the build is 3.8.6. While I was using 3.8.5 and after adding the Maven wrapper (with Maven 3.8.5), the problem was fixed! :)
So there are problems with Maven 3.8.6 and Tycho 2.7.3, I guess.

[cdietrich]

Can you open a tycho bug
Can you also check with tycho 274 snapshots

[LorenzoBettini]

@cdietrich I could open a bug, but my situation is rather complex: it was working in a few projects and failing in others, and I could not detect what was going wrong. I don't think I'm able to provide any reproducible artifact...

[cdietrich]

Hmm that’s is bad . Me neither

[LorenzoBettini]

My impression was that it was failing when the plugin was used in the same project where other Java sources was there, but not yet compiled, that is, in the same project where the grammar is: first MWE2 is executed and then the xtext-maven-plugin was not able to find any Java classes. But, as I said, that was just an impression, and there are too many things going on in this project so it's rather complex to understand what was going on.

[cdietrich]

@laeubi do you have something in mind that could have caused this

[laeubi]

@cdietrich not really as the recent problem with Maven 3.8.6 was in the Workspace reader that is not part of 2.7.x so its hard to guess here without any test-case.

[LorenzoBettini]

@laeubi what do you mean by "was in the Workspace reader"?

[laeubi]

Tycho 3.x contains a new WorkspaceReader component and has caused some problems before, but 2.7.x do not contain the component so it can't cause issues :-)

[LorenzoBettini]

Some more findings: I've seen the same problem in another project with Tycho 2.7.4 Maven 3.8.6 NOT after updating to xtext 2.27 but after switching from 2022-03 to 2022-06! So I guess we're still facing some version range dependency hell in the xtext maven plugin again. I'll try to hunt the problem in the next few days.

[LorenzoBettini]

@cdietrich @laeubi as I said in my previous answer I experience the same problem by switching to 2022-06, and by enabling Maven debugging, I see this WARNING when running xtext-maven-plugin

[WARNING] class "org.eclipse.jdt.internal.compiler.lookup.AptSourceLocalVariableBinding"'s signer information does not match signer information of other classes in the same package

although that's just a warning, I'd bet this is the source of the problem!

In fact, the xtext-maven-plugin fails when compiling an Xbase DSL source file that refers to a Java file in the same project

[cdietrich]

this is eclipse-jdt/eclipse.jdt.core#148

[LorenzoBettini]

Then I guess that's the culprit of the behavior I'm experiencing.
Without -X xtext-maven-plugin does not print anything since that's a warning during

[INFO] Generating stubs into ... target/xtext-temp/stubs
[INFO] Compiling stubs located in ... target/xtext-temp/stubs
[INFO] Compiler source roots: ... target/xtext-temp/stubs

because, IIRC, in that stage, a few compilation errors are expected.

And then the validation of the DSL sources fails with no other information, besides the Java types used by the DSL sources cannot be resolved.

@cdietrich @laeubi If I understand the mentioned jdt.core problem correctly, there's nothing we can do about that... interestingly, this does not happen with Maven 3.8.5, but it does with 3.8.4 and 3.8.6

[laeubi]

Maven 3.8.5 has a bug that misses some of the dependencies from profiles. As I don't know why jdt.core is required here I can't tell if there is a solution, in general one should check the dependency chains and either exclude core or the compiler tools.

[LorenzoBettini]

@laeubi jdt.core is indeed necessary, since in an Xbase DSL the xtext-maven-plugin needs to compile Java sources and make them available to the DSL sources that can refer to Java types. The compiler tools were explicitly added in the past since otherwise, we hit the different version problems (eclipse/xtext-maven#146)

[LorenzoBettini]

this is eclipse-jdt/eclipse.jdt.core#148

@cdietrich by the way, having a look at eclipse/xtext-maven#146 that's exactly the same warning I was experiencing back then, but this time I guess we cannot do anything from our side...

[cdietrich]

i assume this always happens when inconsistent version of jdt.core, jdt.compiler.(ast|tool) end up in the resolved classpath.
with the 2022-06 the problem even happens for consistent versions.

i assume

xsemantics/releng/org.eclipse.xsemantics.parent/pom.xml

Line 568 in fd889e5

<requirement>

will pull the newest of all

[LorenzoBettini]

@cdietrich yes, that's the solution we adopted in eclipse/xtext-maven#146 to make sure to consistently drag in the (Tycho) TP the latest versions of JDT. Now, that's useless since JDT bundles are broken w.r.t. to signatures, which is really bad (not to mention a shame!)