BP_JVM_VERSION should have priority over derivation from MANIFEST.MF #350
Comments
|
The code here should prefer Can you provide some more details about your environment where the issue is happening so we can recreate?
Thanks |
Yes. To be honest I am not familiar with using
The sample project schould help here.
It is set by the Spring Boot Maven Plugin automatically. The sample project is located here: https://github.com/OLibutzki/paketo-buildpacks-libjvm-350 In both builds In the Java 17 build one can find Using Java version 17 extracted from MANIFEST.MF and in the Java 21 one can find Using Java version 21 extracted from MANIFEST.MF. My expectation would have been that Java 17 is chosen, regardless of the Java version I use for building the project. I hope that helps you. |
|
It does help, thanks much! |
|
Java So, |
@modulo11 I can confirm that In my opinion that's a second issue. That issue needs to be addressed to the Spring Boot team. Anyway, this issue is valid, too as Buildpacks uses the Java version used for the build instead of the version which is used to compile the application. |
|
The spring-boot-maven-plugin acts as a platform (@dmikusa please correct me if I'm wrong) which makes certain choices. For example if I specify Using this explicit configuration for the plugin: <build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<env>
<BP_JVM_VERSION>17</BP_JVM_VERSION>
</env>
</image>
</configuration>
</plugin>
</plugins>
</build>in a Java 21 project shows, that the correct choices were made: The current priorities are (lowest to highest):
|
|
Versions of Spring Boot from 2.3 through 2.7 set the
Nothing in the Spring Boot plugins looks for
Yes, the Spring Boot plugins do act as CNB platforms. The design goal is that the plugins don't make choices as much as they provide information and hints in the artifacts provided to buildpacks so that buildpacks can make the choices. Initially we provided hints by setting environment variables in the buildpack invocation, but we have since moved more toward using manifest entries or files contained in the archive as with this JVM version example. The Boot and Paketo teams agreed that putting hints in the jar file is a better approach, as it is more portable across buildpack providers, makes for a more consistent experience with |
|
I got your points, but I have a concrete question/scenario. I have a Spring Boot 3 application which is built against Java 17 ( Building with Java 21 results in a Anyway, if it's not the default to use the Java version the application is compiled against as runtime jdk: How can I explicitly configure to use Java 17 as runtime jdk although I ran the build process with Java 21? |
If you set From @modulo11's example above: That should override to Java 17. |
The typical way of doing this would be to set If this isn't working for you, can you provide a minimal sample that shows what you're trying to do? |
|
Note that you can also set the value of |
|
@scottfrederick thanks! I can confirm that it works, if I set Now I understand what confused me. That's the log without setting That the log with setting In both cases $BP_JVM_VERSION is logged as |
|
I can see what you're saying. When it's not set, it shows the default version which is 17. We try to clarify how the version was selected below the configuration settings. You'll see if it's picked due to the env variable:
You'll see if it's picked due to the manifest setting:
I wouldn't be opposed to trying to differentiate between default and user-specified settings in the config table. I'm not sure off hand how to do that. The table is kind of big and unwieldy already. Adding columns makes that worse. Maybe an asterisk next to default values or something. 🤔 I'll open a new issue for that and close out this one. Let me know if you have thoughts on how we could display that over on the new issue. Thanks |
I'm fine with that idea... @scottfrederick I still think that it would make sense if this would be the default behaviour of the spring-boot-maven-plugin. Don't you think so? |
That's the path we started down with CNB integration in the Spring Boot plugins, but we've moved away from that for a few reasons (all of which also apply to other configuration like First, Spring Boot acts as a CNB platform interacting with the CNB lifecycle. Boot defaults to using Paketo buildpacks, and works closely with the Paketo team, but tries to keep the code agnostic of buildpack providers. Moving away from Paketo-specific env vars toward manifest entries and files gives other buildpack providers the same opportunity to make decisions as the Paketo team has. Second, and IMO more importantly, the current arrangement makes the experience with |
|
@scottfrederick thanks a lot for giving this detailed explanation. Highly appreciated! |
Although a
BP_JVM_VERSIONis passed explicitly, the Java version is derived fromBuild-Jdk-Specin theMANIFEST.MF.See https://github.com/orgs/paketo-buildpacks/discussions/237
Describe the Enhancement
Deriving the Java version from the
MANIFEST.MFmakes sense, but in case there is an explicitBP_JVM_VERSIONgiven that should have precedence.Possible Solution
The possible solution is mentioned in the enhancement description.
Motivation
The motiviation is explained in the linked discussion.
The text was updated successfully, but these errors were encountered: