xtext-maven-plugin has problems when used with Tycho (will soon have) #146
Comments
|
hmm i have no clue where the generator depends on jdt.core. maybe to solve some transitive emf.codegen? i also wonder if there is another tycho solution to the fragment problem. |
|
we simply should stop all the backwards compatibility crap .... |
|
@LorenzoBettini is it guaranteed that the tycho and non tycho deps are ordered in a certain way? |
@cdietrich I'm answering this one first, and then later to the other questions: As far as I know, Maven creates a classpath by first inserting the runtime dependencies of the plugin, the ones in the Note that the Eclipse bundle jdt.core does NOT depend on jdt.compiler.apt, which is a fragment. In fact, Of course, the Eclipse bundle jdt.core (3.26) is inserted first, so when So it's not really a question of tycho deps and non-tycho deps ordered differently: the classpath is created by Maven in the above order. For example, as an extreme borderline solution, just as an example, if you force <plugin>
<groupId>org.eclipse.xtext</groupId>
<artifactId>xtext-maven-plugin</artifactId>
<version>${xtextVersion}</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<languages>
<language>
<setup>org.xtext.example.mydsl.MyDslStandaloneSetup</setup>
<outputConfigurations>
<outputConfiguration>
<outputDirectory>src-gen</outputDirectory>
</outputConfiguration>
</outputConfigurations>
</language>
</languages>
</configuration>
<dependencies>
<dependency>
<!--
Redundant (since xtext-maven-plugin depends on that)
but it forces jdt deps to be taken from Maven instead of
from the TP -->
<groupId>org.eclipse.xtext</groupId>
<artifactId>org.eclipse.xtext.builder.standalone</artifactId>
<version>${xtextVersion}</version>
</dependency>
<dependency>
<groupId>org.xtext.example.mydsl</groupId>
<artifactId>org.xtext.example.mydsl</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</plugin>then everything works, because the old jdt.core and jdt.compiler.apt both appear first: |
@cdietrich but is it really a problem of backwards compatibility? That's not related to Java 8 and Java 11... or I don't understand what you mean |
First of all, from what I understand, the So we could simply remove that. However, as you say, even by removing that we still get it transitively from emf.codegen:
Funny thing: jdt.core is shown to depend on jdt.compiler.apt but it actually doesn't: as I said, jdt.compiler.apt is a fragment of jdt.core
as far as I know, if you want a pure Tycho solution, the |
|
see aalso eclipse/xtext-core#1722 |
|
PING! Before 2.26 this should be fixed... |
|
am not sure if pinging will help. wait for feedback for months now |
|
I know, I know. Shame on me. I am completely under load with my customer also since months, and it has zero to do with anything Xtext, Eclipse, Maven. Whenever I think there is light at the end of the tunnel then it just the train. 😔 |
|
@cdietrich @kthoms OK, let me know what I can do now... I think I've already done what I could do up to now... |
|
i still did not fully understand the problem. i also assume this affects all xbase/common types deps that pull jdt |
|
I did my best to explain the problem and the solution... |
|
:( this arguing makes me want to quit. |
|
it also makes me want to quit as well |
|
I'll try to catch up here finally. First, I could not reproduce the actual problem so far. I have checked out your example project, and it worked out of the box. Then I changed to Target Platform 2021-12 and also to Tycho 2.4.0, both worked. However, I got your main point here. The risk is that a fragment contributes to the same package as the host bundle, but with different signatures, because they do not match (jdt.core, jdt.compiler.apt). To avoid this somehow force that when jdt.core is a project dependency, the fragment is also. From the log I see is that these dependencies are pulled in by Your proposals will work around this issue by making the fragment and jdt.core transitive a project dependency. I like the extraRequirement more than additionalBundles, since it is more visible and only managed in the parent pom. The same issue will arise when another dependency configured as dependency for The drawback is more visible and not obvious configuration, and additional usually unneeded project dependencies. However, still better than breaking by default. |
|
@kthoms thank you for the feedback! It's quite strange you could not reproduce the original problem... I'll check it myself in the next few days. In any case, please tell me how you'd like to proceed. |
|
From my side I would be fine with the "extraRequirements" approach. This should be generated by the wizard. At least in the wizard code there should be a comment why this is added, since one year later no-one would know and that this is "just" a workaround. |
|
@kthoms OK, so I'll create a PR in the next few days following the approach of extraRequirement, which we used in the past, and leave a comment there. (We also do something similar for UI tests in the macOS environment for jdt.launch feature) |
|
any update here? |
|
@cdietrich I'll try to provide a PR as soon as possible. |
|
@LorenzoBettini should i go with M3 without? |
|
@cdietrich I can't assure to work on that in the weekend or on the next week, so I'd say yes. For sure I'll work on that before the final release. For that there's still time, right? |
|
it depends if we release on 31st or postpone it |
|
@LorenzoBettini any update? |
|
@cdietrich I'll try to address that by the end of the week |
|
@LorenzoBettini please be aware we wont postpone release on 28th |
|
@cdietrich sorry I don't understand, do you mean after 28th? |
|
if we dont have a patch in time for the release on feb 28th we will release without a patch |
|
@cdietrich PR eclipse/xtext-core#1833 created |
conflicts with maven dependencies when using tycho in xtext-maven-plugin see eclipse/xtext-maven#146 Signed-off-by: Christian Dietrich <[email protected]>
|
workaround in place. final solution still needs discussion |
|
workaround in place. |
I'm experiencing a few problems migrating to Eclipse TP 2021-06 when using
xtext-maven-pluginto generate Java code from my DSLs (relying on Xbase) when it is run together with Tycho (just to be clear, in a pure Maven project, there's no problem). That's somehow related to the JDT version range dependency hell (see also eclipse-xtext/xtext#1976) and to the new versions of JDT in Eclipse 2021-06. I reproduced the problem in this simple DSL (using Xbase): https://github.com/LorenzoBettini/xtext-maven-plugin-exampleSimple grammar
Simple JvmModelInferrer:
I'll try to detail the problem (it's not easy to understand what's going on) and a few solutions. I think one of such solutions should be somehow provided by Xtext when creating new projects that are meant to be built with Maven/Tycho.
The problem shows up when you use xtext-maven-plugin to generate the Java source of your DSL input file, and such input file refers to a Java source file (so, there's no problem if the DSL file is "self-contained").
For example (https://github.com/LorenzoBettini/xtext-maven-plugin-example/tree/master/org.xtext.example.mydsl.parent/org.xtext.example.mydsl.example), given this helper Java class
and this DLS input file
The xtext-maven-plugin is configured as usual:
The problem raises when you run the Maven/Tycho build when your DSL (i.e., the dependency in the xtext-maven-plugin) has a (possibly transitive) dependency on JDT core. The symptoms are these error messages:
Unfortunately, there's no other information. If you enable
-Xyou get something more:In fact, what's happening is that
org.xtext.example.mydsldrags in as a transitive dependency jdt.core (the new version 3.26 from the TP 2021-06) andorg.eclipse.xtext:org.eclipse.xtext.builder.standalone:jar:2.25.0drags inorg.eclipse.jdt:org.eclipse.jdt.core:jar:3.23.0(but too late, so the newer version 3.26 from TP will be used) andorg.eclipse.jdt:org.eclipse.jdt.compiler.apt:jar:1.3.1100, which is too old for JDT core 3.26 (the newer version is 1.3.1300) and so we have the "does not match signer information" problem above that breaks everything (well, it does not allow xtext-maven-plugin to compile the stub classes and later the DSL input cannot find the Java class).Now, why does
org.xtext.example.mydslhave a transitive dependency on jdt.core? Actuallyorg.eclipse.xtext.xtext.generatordepends on jdt.core (optionally, but Tycho finds it, so it uses that). Butorg.eclipse.xtext.xtext.generatoris in theadditional.bundlesofbuild.propertiesand Tycho ignoresadditional.bundles... well it does now because of a bug, which has been fixed in the forthcoming 2.4.0.Summarizing, the problem will show up when updating to 2021-06 and Tycho 2.4.0. Or, even without using Tycho 2.4.0, when you have a required bundle dep on anything that depends on jdt.core.
Solutions
The idea is to force the newer version of
jdt.compiler.aptthat works withjdt.core. Or, in any case, to make sure thatjdt.compiler.aptis taken from the same dependency context asjdt.core.Each solution is in a separate branch (built with GitHub Actions on Linux, macOS and Windows)
Explicit Maven dependencies in the plugin configuration
Force all the needed jdt dependencies (and yes, due to the version ranges of jdt, also of runtime and equinox to avoid further problems), see https://github.com/LorenzoBettini/xtext-maven-plugin-example/blob/explicit-jdt-deps/org.xtext.example.mydsl.parent/org.xtext.example.mydsl.example/pom.xml
I find this solution not easy to maintain: you have to keep it in sync with the version of JDT from the TP. Moreover, it cannot be easily handled by Xtext itself. Remember that the BOM does not work with plugin dependencies.
Explicit dependency in the additional.bundles
Since Tycho 2.4.0 will support additional.bundles, we can add
org.eclipse.jdt.compiler.aptin theadditional.bundlesof the DSL plugin project; this way, the same version as the one in the TP will be used, see https://github.com/LorenzoBettini/xtext-maven-plugin-example/blob/explicit-compiler.apt-in-additional.bundles/org.xtext.example.mydsl.parent/org.xtext.example.mydsl/build.properties:This is much easier to maintain: once the dependency is there nothing else is required.
NOTE:
org.eclipse.jdt.compiler.aptis a FRAGMENT so it must be added manually (cannot be added with the Eclipse editor). This fix can be generated by the Xtext generator itself since it should be able to handlebuild.propertiesif I remember correctly.Remember though, that this is based on Tycho 2.4.0. For older versions, it must be a required bundle (possibly optional).
Tycho target-platform-configuration
Add
org.eclipse.jdt.compiler.aptas an extra requirement in thetarget-platform-configuration. In Xtext projects there are already a few of them (org.eclipse.rcp and xtext.logging), see https://github.com/LorenzoBettini/xtext-maven-plugin-example/blob/explicit-compiler.apt-in-target-platform-configuration/org.xtext.example.mydsl.parent/pom.xmlThat's my favorite one: it does not touch the projects and solves the problem at the right level (that is, in Maven/Tycho POM), it works for all versions. Again the Xtext wizard can generate that, as it generates the POMs.
The text was updated successfully, but these errors were encountered: