You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Graal as well as Mandrel are tightly coupled to the OpenJDK used to build them. As we push out new releases it would be nice to be able to keep track of a map from Mandrel versions to OpenJDK versions so that in the future we can come back and build an older version using the OpenJDK that was available at the time.
Following a similar approach would enable us to checkout at any time any version and using mandrel-packaging build mandrel with the correct JDK version, e.g. if you try to build 20.1.0.2 it would use 11.0.8-GA but if you try to build say 20.1.0.5 it would use 11.0.9-GA etc.
We can even have something similar to graalvm with JAVA_HOME and EXTRA_JAVA_HOMES to define more than one JDK versions that are known to work with the corresponding mandrel version (or that we would like to test, although this won't work right in GH actions, but maybe Jenkins can take advantage of it)
The text was updated successfully, but these errors were encountered:
Graal as well as Mandrel are tightly coupled to the OpenJDK used to build them. As we push out new releases it would be nice to be able to keep track of a map from Mandrel versions to OpenJDK versions so that in the future we can come back and build an older version using the OpenJDK that was available at the time.
Graal uses https://github.com/graalvm/mandrel/blob/graal/master/common.json to keep such info in the sources. This file gets updated as new JDK's become available etc.
Following a similar approach would enable us to checkout at any time any version and using mandrel-packaging build mandrel with the correct JDK version, e.g. if you try to build 20.1.0.2 it would use 11.0.8-GA but if you try to build say 20.1.0.5 it would use 11.0.9-GA etc.
We can even have something similar to graalvm with JAVA_HOME and EXTRA_JAVA_HOMES to define more than one JDK versions that are known to work with the corresponding mandrel version (or that we would like to test, although this won't work right in GH actions, but maybe Jenkins can take advantage of it)
The text was updated successfully, but these errors were encountered: