Native support for Eclipse SDKs on Windows Arm64

[chirontt]

Update: now that adding support for Windows on Arm64 is under way for various Eclipse repositories, here's the central TODO list to keep track of various tasks done and/or under way:

• support for Eclipse on Windows on Arm64 platform java-native-access/jna#1466
• add support for Windows on Arm64 to eclipse.platform.swt submodule
  • Handle validation of uxtheme.dll undocumented exported functions in ARM64 builds eclipse.platform.swt#1048
  • Compile SWT natives for Windows on Arm64 (WoA). eclipse.platform.swt#1045
  • Update WebView2Loader.dll to WebView2 1.0.1150.38 eclipse.platform.swt#1137
  • Make requirement of o.e.swt for swt.win32.aarch64 temporarily optional eclipse.platform.swt#1158. This is temporary measure to have successful build; to be reverted later.
    • Revert "Make requirement of o.e.swt for swt.win32.aarch64 temporarily optional" eclipse.platform.swt#1222
  • [win32][arm64] Support Dark Theme on newer Windows builds eclipse.platform.swt#1172
• add support for Windows on Arm64 to equinox submodule
  • Add support for Windows on Arm64 (WoA). eclipse-equinox/equinox#559
  • Migrate equinox.security.win32 to JNA to enhance CPU-arch compatibility eclipse-equinox/equinox#564
  • Integrate Equinox launcher and executable natives build into the Equinox Jenkins pipeline eclipse-equinox/equinox#575
  • [Build] Perform native binaries build as part of the Jenkins pipeline eclipse-equinox/equinox#603
  • Remove temporary win32.aarch64 environment from exe-feature eclipse-equinox/equinox#621
• add support for Windows on Arm64 to rt.equinox.p2 submodule
  • Adapt to equinox.security.win32 renaming and adjust arch requirements eclipse-equinox/p2#492
• add support for Windows on Arm64 to eclipse.platform submodule
  • Add missing SWT for Windows on Arm64 (WoA) fragment eclipse.platform#1311
  • Auto-refresh fragment for Windows on Arm64 (WoA) platform. eclipse.platform#1350
  • Native file info fragment for Windows on Arm64 (WoA) platform. eclipse.platform#1351
  • Migrate the Windows native file-system refresh monitor to JNA eclipse.platform#1394
• add support for Windows on Arm64 to eclipse.platform.ui submodule
  • Add org.eclipse.swt.win32.win32.aarch to org.eclipse.e4.rcp feature eclipse.platform.ui#1789
  • Add support for Windows on Arm64 (WoA) platform build. eclipse.platform.ui#1787
• add support for Windows on Arm64 to eclipse.platform.releng.aggregator
  • Adapt to equinox.security.win32 renaming and adjust arch requirements #1942
  • The SDK4Mvn.aggr needs a win32/win32/aarch64 configuration #1953
  • Add win32.aarch64 environment to eclipse-platform-parent and publish win32.aarch64 artifacts #1917
  • [I-Build] Copy built products for Windows on Arm to publication area #2017
• Add N&N for support of Windows on ARM www.eclipse.org-eclipse#169
• Packages for Windows on ARM eclipse-packaging/packages#162

---

I'm trying to build the Eclipse SDKs for Windows 11 on Arm64 (WoA), using this repo. I hope this is the right repo to start with, which is the umbrella repo for all others.

The environment triplet I use for it is win32/win32/aarch64, following the existing win32/win32/x86_64 triplet as a guide.

After re-compiling many *.exe and *.dll native files for WoA in various repos (from existing C code mostly unchanged), and adding many new win32.aarch64 folders (most of them are duplicates of the existing win32.x86_64 ones), I've managed to build successfully this aggregator repo, and got the following new zip files in eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/target/products (in addition to other supporting os/arch zip files there):

org.eclipse.platform.ide-win32.win32.aarch64.zip
org.eclipse.sdk.ide-win32.win32.aarch64.zip

After unzipping the org.eclipse.sdk.ide-win32.win32.aarch64.zip file, I discover that, in its eclipse/plugins folder, the following 6 bundles are missing:

org.eclipse.core.filesystem.win32.aarch64_<version>.jar
org.eclipse.core.net.win32.aarch64.source_<version>.jar
org.eclipse.core.net.win32.aarch64_<version>.jar
org.eclipse.core.resources.win32.aarch64_<version>.jar
org.eclipse.equinox.security.win32.aarch64.source_<version>.jar
org.eclipse.equinox.security.win32.aarch64_<version>.jar

When compared to the org.eclipse.sdk.ide-win32.win32.x86_64.zip distribution, those bundles (of relevant x86_64 arch) do exist there. So somehow they got missing from the final zip file for aarch64 during the build.

The missing bundles are crucial for the Eclipse SDK to properly start up, but I have no idea how they got missed out from the build artifacts. I think I must have skipped over some crucial file(s) somewhere which produced this missing result.

Is there a file somewhere in the repo to indicate which bundles to be included (in the plugins folder of the zip file) for each SDK?

PS. The missing bundles are actually produced in their own Maven modules during the build, in the eclipse.platform & equinox submodules. Once I manually add 4 of them (the other 2 are source bundles) to the plugins folder, and also add their missing entries to the configuration\org.eclipse.equinox.simpleconfigurator\bundles.info file, starting it up with eclipse.exe works nicely!

PPS. Especially and crucially for WoA, eclipse.exe can only start up after I add the -Dorg.osgi.framework.os.name=win32,win entry to the eclipse.ini file, to help it resolve the critical com.sun.jna bundle at runtime.

[merks]

Did you update the features to include the new fragments?

[chirontt]

@merks thanks for the tip. Your picture is worth more than a thousand words to me. Now I can build the Eclipse SDKs for WoA and they work!

Next is where/what is the repo to build the Eclipse IDE (which should include other tools like JGit/EGit, m2e, etc.) for WoA?

[merks]

The repository used to build the IDE are composed from many projects. There's information about that here:

https://ci.eclipse.org/simrel/

This file has information about all the projects involved:

https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/simrel.aggran

Quite of a few of the project has Oomph setups that you can use to setup an an IDE; many of them you'd have to do manually.

[mickaelistria]

I don't think you'll need to change many other projects. The very vast majority of them wouldn't have Platform specific artifacts, and I don't have the impression fixing those is an immediate requirement for you.
As @merks pointed, you might want to make the SimRel build capable of including the win32/aarch64 artifacts; adding a relevant line at https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/simrel.aggr#n74 . But SimRel references p2 repositories, so you'll need to tweak it to reference a p2 repository that contains the win32/aarch64 SDK, which might not be easy.
Then, from SimRel, the "Eclipse IDE" is build with https://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/ ; there are some pom.xml and .product files in here you'll also need to modify for this new platform to be considered.

But this is a multi-step process. My advice would be that -if you're willing to make your work sustainable and to contribute it to Eclipse Project-, now that you have a build working, you find a way to get a win32/aarch64 machine contributed to the build farm and contribute your changes to the Eclipse Platform/SDK project to get this Platform supported. Going to "official" SDK and p2 repo will already be a major milestones and will make it easier to cascade later on to SimRel/EPP...

[chirontt]

As to the problem with JNA bundle in WoA:

PPS. Especially and crucially for WoA, eclipse.exe can only start up after I add the -Dorg.osgi.framework.os.name=win32,win entry to the eclipse.ini file, to help it resolve the critical com.sun.jna bundle at runtime.

I've raised an issue with the JNA project: java-native-access/jna#1465

[chirontt]

@mickaelistria My Arm64 box is an entry-level, slow box, suitable for some light, manual testing only. I had started building this repo with this Arm64 box, and it was a big exercise in patience. I eventually gave it up and switched to building on a Linux (x64) box instead. It takes around 1 hour to build this repo on the Linux box without running the tests (i.e. with -DskipTests=true). The Arm64 box becomes a test machine for some manual testing of the resulting SDKs. So I don't think it's a good addition to your build farm.

The good news is that you don't need an Arm64 box to build these SDKs for WoA. I can build and produce all SDKs for all os/arch (WoA included) with my Linux (x64) box, so your existing build farm can build the WoA distribution too, once my work on WoA are accepted in to the official repos. The recompiled binaries for Arm64 would be checked in to the repos like other existing binaries currently for other os/arch, so that the build wouldn't depend on any platform-specific tools to run.

From the look of it, building the Eclipse IDE for WoA is more than I can chew at the moment, so for now I will concentrate on submitting PRs for this WoA work to various repos (9 total, including this repo), to get the official Platform/SDK build started for WoA!

[mickaelistria]

@chirontt OK, thanks for the details. So if you have things that you could already contribute, please do so and we'll see what we can merge easily. But at some point, to guarantee good enough quality, we'll need to have the SDK tests running automatically on a win32/aarch64 machine. Without it, then the project cannot prevent from potential regressions easily, and we basically cannot provide good enough support ot make it reliable; which IMO kind of question the value of hosting this specific code in the Eclipse project instead of eg in some fork of yours.

[chirontt]

Can this aggregator build be run for Windows on Arm64 only, i.e. for win32/win32/aarch64 environment triplet only? How should it be configured?

If so, I would try to build just for this WoA platform on my Arm64 box, including running the tests, to see how it would fare in producing the SDKs for WoA. I can't give any promise at the moment, though.

BTW, I've started sending out the PRs for this WoA work.

[mickaelistria]

Some of the CI issues such as the ones about not found bundles in https://ci.eclipse.org/equinox/job/equinox/job/PR-121/1/console are caused by the missing win32/win32/aarch64 declaration in the parent pom: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse-platform-parent/pom.xml#L254 . Please try adding the environment there and if build is fine, submitting a PR for that.
If you want to try a local build skipping other environments, you can comment them out.

[akurtakov]

We can have the bundles but can't include them in features/products until we have the builder to ensure that they are rebuild on source changes.

[chirontt]

Sorry for the confusion in my partial submission of PRs. I ran out of time yesterday, and only managed to submit the PRs for eclipse-equinox repos.

Now I've done all other PRs for eclipse-platform repos, to complete this WoA submission to mainline.

My guess is that all these PRs need to go in together for a successful build, as they are inter-related, but you may have better idea about them.

[akurtakov]

I'll repeat it:
We can not include native win32 aarch fragments in features unless we have a builder in our JIPPs allowing to rebuild them on e.g. source change in SWT. Until this happens we can only have sources that can't end up in deliverables.

[akurtakov]

@daliasheasha You was interested in Eclipse on Windows AArch64. Maybe you can help with some builder?