Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Provide GraalVM metadata repository support with Buildpacks
See original GitHub issue(edit)
Splitting into sub-tasks:
External issues:
- https://github.com/graalvm/native-build-tools/pull/322
- https://github.com/paketo-buildpacks/native-image/issues/196 & https://github.com/paketo-buildpacks/native-image/pull/201
As discussed with @dmikusa-pivotal, @mhalbritter and @scottfrederick, we need to integrate GraalVM metadata repository in Buildpacks in addition to Native Build Tools current support (see #31687) in order to allow compiling Spring Boot application with third-party dependencies to a native executable. 2 implementations have been discussed.
Based on our discussions, integration at Spring Boot Maven and Gradle plugin AOT generation level is the recommended way to implement such integration because:
- It allows a single and consistent way to provide third-party native configuration for Spring Boot applications
- It can leverage graalvm-reachability-metadata Java library and its
GraalVMReachabilityMetadataRepositoryclass maintained by GraalVM team. - Reference implementation in NBT Gradle and Maven plugins can help us for the Spring Boot implementation.
- Conceptually a good fit to put third party hints along to Spring ones
- Better DevXP (all the JSON hints generated at the same location at the same time)
- Better build reproducibility
- Gives more control to Spring Boot on the reachability metadata repository release a certain version of Spring Boot uses
The alternative way is to have 2 distinct implementations : the one at NBT plugins level and another at Buildpacks level, but the lack of consistency, poorer DevXP, the fact that we would likely have to reimplement graalvm-reachability-metadata in Go and maintaining it seems to indicate this should not be the way to move forward.
Issue Analytics
- State:
- Created a year ago
- Comments:22 (20 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@philwebb So my discussion with @vjovanov confirmed there is no hope for bringing back support for
--exclude-configinMETA-INF/native-image/native-image.properties. So I think that means we should move forward with the solution described above.We have already discussed this possibility with the GraalVM team in the past which has been refused, no hope to see this happening short/middle term.