Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: increased target platform to eclipse release 2021-06, as that brings support for platform 'macosx.aarch_64' #150

Merged
merged 3 commits into from
Jan 9, 2023

Conversation

sailingKieler
Copy link
Member

@sailingKieler sailingKieler commented Dec 20, 2022

  • increased Xtext version to 2.25 as also brought by eclipse 2021-06
  • updated the various target platform definitions: switched to orbit release R20210223232630, since R20210602031627 brings 'com.google.inject:5.0.1' that I wanna exclude for now
  • updated the update site p2 repo setup definitions
  • switched to JDK 11 for the build container, as eclipse 2021-06 requires JavaSE-11 at runtime, and running the tycho surefire tests requires the launch of an equinox container
  • increased Tycho version to 2.5, as the 'aarch64' platform is not handled or broken in earlier versions, had to increase the version of 'org.jboss.tools.tycho-plugins:repository-utils' consistently because of an internal failure of v1.0.0 with Tycho v2.5
  • klighd.piccolo.batik: trimmed compile classpath to those jars being actually required by our code to avoid compile errors with Java 9+
  • fixed/refined test failures of 'FreeHEPSVGOffscreenRenderingTest' and 'ViewChangedNotificationTest'

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch 6 times, most recently from 921e8b9 to caa1df6 Compare December 21, 2022 21:48
@sailingKieler
Copy link
Member Author

sailingKieler commented Dec 21, 2022

addresses #97, #132 and #100 to some extent, as well as #134

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch 2 times, most recently from 6a29479 to 3d54c4b Compare December 22, 2022 15:29
Copy link
Member

@NiklasRentzCAU NiklasRentzCAU left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Just have two questions added in the review below.

Comment on lines +35 to +44
<!-- Update: With https://github.com/eclipse-tycho/tycho/pull/145 (Tycho v2.4.0) the aforementioned issue is fixed.
However, just dropping the <associateSites>...</associateSites> argument and keeping the web content
generation doesn't work here, as this mojo _always_ clears the existing repository references,
or crashes if 'content.jar' doesn't exist. Hence, just binding it to an early build phase doesn't work.
Therefore I submitted PR https://github.com/jbosstools/jbosstools-maven-plugins/pull/88
to fix that, let's see how the committers assess it. -->
<plugin>
<groupId>org.jboss.tools.tycho-plugins</groupId>
<artifactId>repository-utils</artifactId>
<version>1.0.0</version>
<version>2.5.0</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What speaks against using the eclipse.tycho tycho-p2-repository-plugin here with the newer tycho release used in the build? From what I tested that should work as well without the need for the duplication of the associate sites here in the pom.xml

Copy link
Member Author

@sailingKieler sailingKieler Dec 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to skip that, but ... see

<!-- Update: With https://github.com/eclipse-tycho/tycho/pull/145 (Tycho v2.4.0) the aforementioned issue is fixed.
However, just dropping the <associateSites>...</associateSites> argument and keeping the web content
generation doesn't work here, as this mojo _always_ clears the existing repository references,
or crashes if 'content.jar' doesn't exist. Hence, just binding it to an early build phase doesn't work.
Therefore I submitted PR https://github.com/jbosstools/jbosstools-maven-plugins/pull/88
to fix that, let's see how the committers assess it. -->

Comment on lines 55 to 65
<associateSite>https://download.eclipse.org/releases/2021-06/</associateSite>
<!-- UML2 Tools (Meta Model Implemenetation, ...) -->
<associateSite>https://download.eclipse.org/modeling/mdt/uml2/updates/5.4/</associateSite>
<!-- Eclipse Layout Kernel -->
<!-- associateSite>http://build.eclipse.org/modeling/elk/updates/nightly/</associateSite -->
<associateSite>https://download.eclipse.org/elk/updates/releases/0.8.1/</associateSite>>
<!-- Xtext -->
<associateSite>https://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.22.0/</associateSite>>
<associateSite>https://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.25.0/</associateSite>>
<associateSite>https://xtext.github.io/download/updates/releases/2.1.1/</associateSite>>
<!-- Eclipse Orbit for Google Guave, Apache Batik, ... -->
<associateSite>https://download.eclipse.org/tools/orbit/downloads/drops/R20200529191137/repository/</associateSite>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this update the Eclipse release, but not its associate orbit release? There might appear inconsistencies because of this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I overlooked that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

switched to orbit release R20210223232630 instead of R20210602031627, since R20210602031627 brings 'com.google.inject:5.0.1' that I wanna exclude for now

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch from 3d54c4b to 54493c0 Compare January 2, 2023 15:22
@sailingKieler
Copy link
Member Author

I updated the referenced orbit repository in the target platform and repository defs.

@NiklasRentzCAU, @soerendomroes, @a-sr Do you guys wanna do some internal testing before merging and give me a final 'go'?

@soerendomroes
Copy link
Member

Yes, I think it would be better if we could do that.

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch from 54493c0 to 8a2f060 Compare January 5, 2023 13:23
@sailingKieler
Copy link
Member Author

Yes, I think it would be better if we could do that.

@soerendomroes Can you give me a hint on when?

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch 2 times, most recently from 4191513 to 90978e7 Compare January 5, 2023 16:46
@soerendomroes
Copy link
Member

Yes, I think it would be better if we could do that.

@soerendomroes Can you give me a hint on when?

I guess we will have a look next week when everyone is in the office again.

@soerendomroes
Copy link
Member

I tested the target platform by building the KIELER and the LS and both seem to work on Ubuntu. @a-sr @NiklasRentzCAU do you want to test something else?

Copy link
Member

@a-sr a-sr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good to me.
@soerendomroes No, I don't think we need further testing. I trust your assessment.

@NiklasRentzCAU
Copy link
Member

On new review after your changes, still looks good. As the build and our KIELER tooling still works with this I see no problems.
Regarding your comment about Java 8 compatibility: I would like to drop the Java 8 support in an upcoming release altogether because of its EoL last year. Do you think this may cause problems for other users when I commit that change in an upcoming PR?

@sailingKieler
Copy link
Member Author

Regarding your comment about Java 8 compatibility: I would like to drop the Java 8 support in an upcoming release altogether because of its EoL last year. Do you think this may cause problems for other users when I commit that change in an upcoming PR?

The question ist: What would be benefit for KLighD? KLighD's SWT-related parts don't need anything else (as of now).
For test code we can easily increase it, and similarly for the LSP stuff you can increase the target compatibility (via B-REE and/or the maven property) locally, too.

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch from fdb1252 to 5e3679f Compare January 9, 2023 14:15
…ctually required by our code, fixes #97

This avoids the 'The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml' error that is due to fact that classes of the 'org.w3c.dom' package are part of the JDK since Java9 (in module 'java.xml'), and also part of the packaged batik 1.7 distribution.

At runtime classes of the JDK/JRE will take precedence (root class loader is asked first), so their counterparts in the provided jar won't be loaded.
…ings support for platform 'macosx.aarch_64‘, contributes to #100

* increased Xtext version to 2.25 as also brought by eclipse 2021-06
* updated the various target platform definitions: switched to orbit release R20210223232630, since R20210602031627 brings 'com.google.inject:5.0.1' that I wanna exclude for now
* updated the update site p2 repo setup definitions
* switched to JDK 11 for the build container, as eclipse 2021-06 requires JavaSE-11 at runtime, and running the tycho surefire tests requires the launch of an equinox container
* increased Tycho version to 2.5, as the 'aarch64' platform is not handled or broken in earlier versions, had to increase the version of 'org.jboss.tools.tycho-plugins:repository-utils' consistently because of an internal failure of v1.0.0 with Tycho v2.5

fixup targetplatform
…tionTest' to pass on linux again (font size diffs :-/ ), made 'FreeHEPSVGOffscreenRenderingTest' more robust wrt. non-determinisms caused by hash maps and the like, fixes #132

 * dropped dependency to Xbase from 'kieler.kgraph.text' & '.ide', added JDT-free binding of 'IAllContainersState' in KGraphUiModule in 'kieler.kgraph.text.ui'
@NiklasRentzCAU
Copy link
Member

The question ist: What would be benefit for KLighD? KLighD's SWT-related parts don't need anything else (as of now). For test code we can easily increase it, and similarly for the LSP stuff you can increase the target compatibility (via B-REE and/or the maven property) locally, too.

The benefit ist having new releases not be dependent on an EoL Java Version and not having to face further complications with more projects and dependencies requiring Java 11+ themselves, see the test project for example. If someone wants to continue using KLighD with Java 8 they then need to use an older release or update their Java version (which is advisable anyways imo).

Feel free to merge this though, we can continue this discussion on Java11+ later

@sailingKieler sailingKieler force-pushed the cs-targetPlatformUpdate branch from 5e3679f to 3c5c884 Compare January 9, 2023 18:30
@sailingKieler sailingKieler merged commit 7be8d36 into master Jan 9, 2023
@sailingKieler sailingKieler deleted the cs-targetPlatformUpdate branch January 9, 2023 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants