cdietrich
commented
3 years ago only if you allow the module access. see also https://github.com/eclipse/xtext-core/issues/393 and only with source/target 11
so can you test with the guice501 prototype?
Closed DanySK closed 1 year ago
cdietrich
commented
3 years ago only if you allow the module access. see also https://github.com/eclipse/xtext-core/issues/393 and only with source/target 11
so can you test with the guice501 prototype?
LorenzoBettini
commented
3 years ago @DanySK see also the workaround in https://www.eclipse.org/forums/index.php/t/1107994/
DanySK
commented
3 years ago @cdietrich as far as I can find instructions on how to target the prototype and it is something I can do while pointing to Central as the sole Maven repo I can surely try and provide feedback. My current plan is to try with 2.26.M1 (which seems to be the latest on Central), force Guice 5.0.1, apply the workaround suggested by @LorenzoBettini and see what happens.
If I understand correctly though, I'm losing the ability to target Java 8, is that correct?
cdietrich
commented
3 years ago @DanySK the patch is not in M1 / on master yet at it lacks testing beside what lorenzo tested
LorenzoBettini
commented
3 years ago @cdietrich as far as I can find instructions on how to target the prototype and it is something I can do while pointing to Central as the sole Maven repo I can surely try and provide feedback. My current plan is to try with 2.26.M1 (which seems to be the latest on Central), force Guice 5.0.1, apply the workaround suggested by @LorenzoBettini and see what happens.
If I understand correctly though, I'm losing the ability to target Java 8, is that correct?
@DanySK My workaround in the Xtext forum can be applied without switching to Guice 5.0.1, on the very contrary, it is a workaround to build your language with Java 16 in the presence of any library that accesses Java internal packages.
Concerning switching to Guice 5.0.1, I don't think you'll lose the ability to Java 8
cdietrich
commented
3 years ago yes java 8 also should work fine with the guice501 branch. the problem will come when we also want to support --target 16/17
DanySK
commented
3 years ago @LorenzoBettini is there a way to selectively pass --illegal-access=permit to Maven only when Java 16 is being used? It works on Java 9+ now but fails on Java 8.
I am currently specifying the option in the .mvn/jvm.config file, and the current idea I'm thinking of is to write a script that deletes the file if the default JVM is java 8, but that's SUPER fragile.
I really wish Xtext could generate the Eclipse plugin using a Gradle build in place of the Maven one, that would simplify exotic build configurations a lot.
LorenzoBettini
commented
3 years ago @DanySK Yes! I guess you're asking for your CI build? If you're using GitHub Actions you can do something like that: https://github.com/LorenzoBettini/xtext-build-utils/blob/b317189983014a0961c53c1008ff0258324829ce/.github/workflows/maven.yml
DanySK
commented
3 years ago No, I wanted to deal with it maven side, so that after clone, by simply launching maven, the build would work regardless of the Java version installed. I "solved" (it's a workaround of a workaround) via CI:
https://github.com/Protelis/Protelis-Parser/commit/c371ebad4f90d63bc2bd0285a6f228059ce87f80
(my setup is slightly more elaborate as I got a centralized place hosting and echoing build configurations to multiple projects)
LorenzoBettini
commented
3 years ago OK!
@DanySK in case you want to try the Guice 5 things, I added a few (hopefully instructions) instructions here https://github.com/eclipse/xtext-core/issues/393#issuecomment-859685083
in my tests, with Guice 5 and Java 16 you can get rid of the additional --illegal-access=permit
DanySK
commented
3 years ago Nice!
I can test it on Protelis (parser) to test whether it works, if it is useful to the Xtext devs. But I won't be able to get it in production until all the artifacts hit Central.
Let me know!
On Fri, Jun 11, 2021, 18:13 Lorenzo Bettini @.***> wrote:
OK!
@DanySK https://github.com/DanySK in case you want to try the Guice 5 things, I added a few (hopefully instructions) instructions here eclipse/xtext-core#393 (comment) https://github.com/eclipse/xtext-core/issues/393#issuecomment-859685083
in my tests, with Guice 5 and Java 16 you can get rid of the additional --illegal-access=permit
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/xtext/issues/1974#issuecomment-859689513, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPGH6N7NYWW5MABE26RYRTTSIY3HANCNFSM46OSG4EA .
cdietrich
commented
3 years ago Yes I am very interested for this to be tested with real world projects
LorenzoBettini
commented
3 years ago @cdietrich I seem to understand that Guice 5 usage has been merged and should be available in 2.26?
cdietrich
commented
3 years ago yes
jpaw
commented
3 years ago Could we get some 2.26.0.M2 with the merged guice 5, or do you plan to release 2.26.0 soon?
cdietrich
commented
3 years ago we will do a m2 once we have a complete feature set for that. we dont have a 2.26 release planned yet.
cdietrich
commented
3 years ago Hi all,
I am pleased to announce the availability of Xtext 2.26.0.M2. This is the first version that won't explode with Java 17 thanks to an update to Google Guice 5.0 (run with Java 17 against 8/11 target, running against 17 will follow next year when platform/jdt and other upstream dependencies also support it) We also did some changes to how recovery builds are scheduled https://github.com/eclipse/xtext-eclipse/issues/1710
Release Notes (WIP) are at https://github.com/eclipse/xtext/blob/website-master/xtext-website/_posts/releasenotes/2022-01-31-version-2-26-0.md
For both we strongly encourage you to test and give feedback.
You can find the milestone at https://download.eclipse.org/modeling/tmf/xtext/updates/milestones/S202110010541/ and http://www.eclipse.org/modeling/download.php?file=/modeling/tmf/xtext/downloads/drops/2.26.0/S202110010541/tmf-xtext-Update-2.26.0.M2.zip and soon on Maven Central
Happy Xtexting
Thanks and Regards Christian
jpaw
commented
3 years ago Hi, thanks a lot for the milestone build. After initial struggles to find the MWE dependencies 2.12.2.M1 I could build my DSL. I changed the MWE updatesite in the target files to https://download.eclipse.org/modeling/emft/mwe/updates/milestones/S202108160852/ and a subsequent mvn -U worked fine. Initial tests with the Corretto 17 JDK all went fine, and no more complaints by the xtend or xtext plugins.
Best regards, Michael
jpaw
commented
3 years ago Hi, I encountered some problems. In a project with xtext-maven-plugin (generating java code into src/generated/java) and xtend-maven-plugin, xtend does not seem to find the generated java code. I used JDK 11 and 17, both show the same effect. maven version is 3.8.1, the source folder is declared as follows:
<plugin>
<!-- For Xtext and Xtend we must add the generated sources to the java source search path -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/generated/java</source>
<source>src/main/xtend</source>
<source>src/main/xtend-gen</source>
</sources>
</configuration>
</execution>
...hi, did this ever work? e.g. with Xtext 2.25? in the past i had to compile the xtend code with the xtext-maven-plugin in this case too https://www.nikostotz.de/blog/combine-xcore-xtend-ecore-and-maven/.
do the plugin work in the correct order? does the xtext-maven-plugin see the source folder?
if yes create a dedicated ticket.
i am also not aware of changes that could cause it
LorenzoBettini
commented
3 years ago Are you sure xtext-maven-plugin actually generates any source files? Maybe you're hit by https://github.com/eclipse/xtext-maven/issues/146
jpaw
commented
3 years ago The project worked well with xtext 2.25.0 (and all prior releases). The project is pure maven, no tycho involved.
I've run mvn -X using xtext 2.25.0 and 2.26.0.M2.
There is a difference: the configuration element of xtext-maven-plugin lists one additional element, namely:
<addOutputDirectoriesToCompileSourceRoots default-value="true"/>
That is the only difference I can spot.
cdietrich
commented
3 years ago this would be this change. https://github.com/eclipse/xtext-maven/commit/165c24df652c628604d5e5ef4947ed002d195287 would need a reproducer though to analyze does it work if you set it to false?
@imhotep82 any idea?
jpaw
commented
3 years ago Yes, that cures the problem! I added
<addOutputDirectoriesToCompileSourceRoots>false</addOutputDirectoriesToCompileSourceRoots>
to the configuration of xtext-maven-plugin, and now it works as before!
Thanks a lot!
szarnekow
commented
3 years ago Does it also work if you remove that option and remove the generate-source plugin? I'm referring to the following part of your pom:
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/generated/java</source>
<source>src/main/xtend</source>
<source>src/main/xtend-gen</source>
</sources>
</configuration>
</execution>If I remove that (the configuration for the build-helper-maven-plugin), Xtend cannot find its source files any more.
heinrichWeichert
commented
3 years ago @jpaw: You would also need to configure the xtext-maven-plugin a litle bit differently. Could you take a look at https://github.com/eclipse/xtext-maven/blob/master/org.eclipse.xtext.maven.plugin/src/test/resources/it/generate/trace/pom.xml and verify/post your configuration?
heinrichWeichert
commented
3 years ago We could also set this new option to "false" if this is a better approach to backwards-compatibility.
jpaw
commented
3 years ago The current configuration of xtext-maven-plugin is as follows:
<plugin>
<groupId>org.eclipse.xtext</groupId>
<artifactId>xtext-maven-plugin</artifactId>
<version>${xtext-maven-plugin.version}</version>
<executions>
<execution>
<id>compile</id>
<phase>process-sources</phase>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<javaSourceVersion>11</javaSourceVersion> <!-- could set to 11 now -->
<compilerSourceLevel>11</compilerSourceLevel>
<compilerTargetLevel>11</compilerTargetLevel>
<addOutputDirectoriesToCompileSourceRoots>false</addOutputDirectoriesToCompileSourceRoots>
<sourceRoots>
<sourceRoot>${project.basedir}/src/main/bon</sourceRoot>
</sourceRoots>
<languages>
<language>
<setup>de.jpaw.bonaparte.dsl.BonScriptStandaloneSetup</setup>
<outputConfigurations>
<outputConfiguration>
<outputDirectory>${project.basedir}/src/generated</outputDirectory>
</outputConfiguration>
</outputConfigurations>
</language>
<language>
<setup>de.jpaw.bonaparte.jpa.dsl.BDDLStandaloneSetup</setup>
<outputConfigurations>
<outputConfiguration>
<outputDirectory>${project.basedir}/src/generated</outputDirectory>
</outputConfiguration>
</outputConfigurations>
</language>
</languages>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.jpaw.bonaparte-dsl</groupId>
<artifactId>de.jpaw.bonaparte.dsl</artifactId>
<version>${bonaparte-plugin.version}</version>
</dependency>
<dependency>
<groupId>de.jpaw.bonaparte-dsl</groupId>
<artifactId>de.jpaw.bonaparte.jpa.dsl</artifactId>
<version>${bonaparte-plugin.version}</version>
</dependency>
</dependencies>
</plugin>and for xtend:
<plugin>
<groupId>org.eclipse.xtend</groupId>
<artifactId>xtend-maven-plugin</artifactId>
<version>${xtend-maven-plugin.version}</version>
<executions>
<execution>
<id>compile</id>
<phase>process-sources</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<outputDirectory>${project.basedir}/src/main/xtend-gen</outputDirectory>
<javaSourceVersion>11</javaSourceVersion> <!-- could set to 11 now -->
</configuration>
</execution>
<execution>
<id>test-compile</id>
<phase>process-test-sources</phase>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<testOutputDirectory>${project.basedir}/src/test/xtend-gen</testOutputDirectory>
<javaSourceVersion>11</javaSourceVersion> <!-- could set to 11 now -->
</configuration>
</execution>
</executions>
</plugin>The full project is at https://github.com/Arvato-Systems/t9t/tree/TEST-2.26.0.M2 (Since it's a big one:the module causing the error is t9t-cfg-be, and the chain of parent poms is t9t-settings-be -> t9t-settings -> (root pom)
cdietrich
commented
3 years ago hmm i cannot build that projects. i also wonder if this can be reproduced with a hello world dsl
imhotep82
commented
3 years ago @jpaw The only thing I'm seeing is that "src/generated" differs from "src/generated/java". If a nested compile root is added, perhaps this confuses the compiler. Could you double-check your paths ? Could you try it again with "src/generated/java" instead of "src/generated" ?
cdietrich
commented
3 years ago simple example with "src/generated/" works for me with both 25 and 26.M2
jpaw
commented
3 years ago Yes, the src/generated may look unusual, the reason is that the DSLs generate java as well as sql (generated DDL), and also XSDs in some cases. The remaining path components are added by the generator.
cdietrich
commented
3 years ago but wouldnt that be a usecase for different outlets?
jpaw
commented
3 years ago It would be easy to convert the base path to src/generated/java, and if that is the suggested way I will change it accordingly. Internally I could derive the other paths via relative paths (../resources/xsd, ../sql).
I do not know how to define multiple outlets. How would that be configured?
cdietrich
commented
3 years ago jpaw
commented
3 years ago Thanks a lot! I will try this.
cdietrich
commented
1 year ago Guice Update is done now as well
Hi, is Java 16 supported?
I am trying to upgrade a project developed with Xtext to support the latest Java. I am currently blocked, I tried to generate a fresh project and compile it with Java 16 but I could not get it to work. I traced the issue to an illegal operation by guice no longer tolerated by the Java Module System, solved in guice 5.0.1 (w.r.t. guice 3.0.0 pulled in by the default project). However, even forcing that dependency update did not fix the build (error at the bottom of the message, it seems still related to the JMS...).
I was wondering if Java 16 is supposed to be supported by Xtext 2.25.0 already, and if not what are the plans for the future, as the Java release cycle has become much faster (I've read part of the conversation in #1721 but could not find specific hints).
Thanks