Create build logic for native image of ide

[hohwille]

When #1191 is implemented, the next step is to create the build logic to build the native image:

• [x] extend ide/pom.xml to build the native image
• [ ] extend our github action for releasing devonfw-ide so that native images are build for all major OS (windows x64, linux x64, macOs x64, macOS arm64). This might be rather tricky. It will make a lot of sense to search if some other github project has solved something like this before and get inspiration from their github actions.

[alfeilex]

This action could help to create native-images for different OS's https://github.com/marketplace/actions/github-action-for-graalvm

[hohwille]

Just found the same thing in discussion with Jan and wanted to add here, but @alfeilex was faster. Great 👍 So it seems really easy: https://github.com/marketplace/actions/github-action-for-graalvm#building-a-helloworld-with-graalvm-native-image-on-different-platforms

[alfeilex]

I tried to run the workflow for each OS but there are errors for macOS and windows. Ubuntu works.

macOS: Error: DARWIN does not support building static executable images.

• it seems that macOS does not support --static flag https://github.com/oracle/graal/issues/478 workflow: https://github.com/alfeilex/ide/actions/runs/5784762695/job/15676095099

Windows: workflow: https://github.com/alfeilex/ide/actions/runs/5784762695/job/15676095232

[alfeilex]

Windows also works... it was only because the job for macOS failed and all processing jobs are canceled... I did not know about this behaviour

So we have to fix macOS with this --static problem

[alfeilex]

It seems that removing --static solves the build issue

https://github.com/devonfw/ide/blob/013ced0bbf48fce1fa2a580289ad6edda9e74de2/ide/pom.xml#L160-L162

Do we need --static at all?

[alfeilex]

It seems that removing --static solves the build issue

https://github.com/devonfw/ide/blob/013ced0bbf48fce1fa2a580289ad6edda9e74de2/ide/pom.xml#L160-L162

Do we need --static at all?

It seems that --static is used to import statically all dependencies for the application.

[hohwille]

We have identified a new problem in this story:

• We are triggering a deployment (mvn ... deploy) that should build the product and upload it to nexus.
• In that process we want to build the native image that needs to be part of the product (and an uploaded artifact)
• However, we need different native images per OS (at least windows, mac, linux - we will not support x86_32 but we might later also support mac x64 and mac arm64).
• GraalVM does not support cross-compiling so we need to build the native image for windows on windows, etc. in different containers and sub-processes of the github action that does the release
• As a result we would deploy and upload the artifacts (e.g. ide-cli) in the same version for an official release multiple times to maven central what is IMHO not possible as after a OSSRH stating repo is released the artifact is "immutable" and may never be modified.

We discussed several solutions for this problem. The most simple solution is as following:

• We have a main build (default is linux as for our CI, PR, etc.)
• This main build will NOT build any native images but only builds and deployed the core product so up to the ide-cli as JAR file
• At the end when that core product is successfully deployed, we will trigger the builds of the native image and the final product via 3 parallel containers as sub-builds in the github action. To optimize and save some resources, we can avoid creating a new linux container for this but reuse the existing one for the main build.
• Therefore we create new maven modules per OS that are sub-modules in the ide folder but are not included and referenced from a parent POM in the modules section. So we have ide/«os»/pom.xml at least for the 3 OS/Architecture combinations we want to support. They have the artifactId as ide-«os» so e.g. ide-windows and directly trigger the logic needed to build our final product without using profiles (like native-image).
• My expectation to complete this story is that these new modules will build the native image and then use assembly plugin to build a TGZ file containing that native image, so we can later add additional artifacts like the system content, the documentation, the LICENSE file, etc.).
• The build process for a specific OS would simply run mvn deploy on the according OS module.
• I have no experience with the details of github actions to spawn async sub-builds and even reuse the current disc content, but if possible the state of the main build should be "copied" to the sub-build containers so they can continue on previous work that has been done including the version bumping (removal of -SNAPSHOT) and compilation, building documentation, etc. so these things do not have to be done again. However, if not (easily) possible, we could also repeat that.
• Further, the main build could wait for all 3 sub-builds to complete and finalize the release if all are successful. In that case, we could even create a more "transactional build", that is a release is either successful and all is tagged, pused, deployed, etc. or it is unsuccessful and nothing is changed in git and nothing is released. This is again a nice to have. In most cases the build will either fail early (Tests fail, etc.) or will be successful. However, it could happen that the release is done for the core and maybe for one OS but for the other OS it would fail and we end up with an incomplete release being published on maven central. If we can not avoid that this could happen, it is still OK but maybe we can even archive the "transactional" solution where we would do the "git push" only at the end after all 3 sub-builds have succeeded. To get this story implemented it is IMHO simpler to do it not "transactional" and do the "git push", create release on github, etc. early in the main build and then just spawn the 3 sub-builds with "fire-and-forget" in parallel and hope none of them will fail. In that simple case, you could even clone the git in the 3 sub-builds and somehow switch to the latest release tag and from there re-run the main build locally (without deploy but just as mvn install) and then do the final product build afterwards.

[alfeilex]

Is transferred to https://github.com/devonfw/IDEasy/issues/4