-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to modify the Java distro in the Builder Image #87
Comments
@qu1queee You can currently add one of our other JVM buildpacks to the beginning of a build to swap the JVM distro. For example, with
to use Azul Zulu instead of Bellsoft Liberica JVM distro. There is one caveat in that at the beginning of the The existing JVM distro buildpacks are: |
Hi @ekcasey , thanks, let me take a look on your comment and I will reach back to you if needed. |
@ekcasey thanks again for your help. I took a look on your reply. What we are looking for is to be able to easily swap the In your example, I think you are building a container image with a default For example, if I trigger a ├ Group #9:
│ └ paketo-buildpacks/java@5.0.0
│ └ Group #1:
│ ├ paketo-buildpacks/ca-certificates@2.0.0 (optional)
│ ├ paketo-buildpacks/bellsoft-liberica@7.0.0
│ ├ paketo-buildpacks/gradle@4.0.0 (optional)
│ ├ paketo-buildpacks/leiningen@2.0.0 (optional)
│ ├ paketo-buildpacks/maven@4.0.0 (optional)
│ ├ paketo-buildpacks/sbt@4.0.0 (optional)
│ ├ paketo-buildpacks/executable-jar@4.0.0 (optional)
│ ├ paketo-buildpacks/apache-tomcat@4.0.0 (optional)
│ ├ paketo-buildpacks/dist-zip@3.0.0 (optional)
│ ├ paketo-buildpacks/spring-boot@4.0.0 (optional)
│ ├ paketo-buildpacks/procfile@4.0.0 (optional)
│ ├ paketo-buildpacks/azure-application-insights@4.0.0 (optional)
│ ├ paketo-buildpacks/debug@3.0.0 (optional)
│ ├ paketo-buildpacks/google-stackdriver@3.0.0 (optional)
│ ├ paketo-buildpacks/jmx@3.0.0 (optional)
│ ├ paketo-buildpacks/encrypt-at-rest@3.0.0 (optional)
│ ├ paketo-buildpacks/environment-variables@3.0.0 (optional)
│ └ paketo-buildpacks/image-labels@3.0.0 (optional) based on what you mentioned, what we would expect to see on the ├ Group #9:
│ └ paketo-buildpacks/java@5.0.0
│ └ Group #1:
│ ├ paketo-buildpacks/ca-certificates@2.0.0 (optional)
│ ├ paketo-buildpacks/azul-zulu@1.16.0 <------ this is a fake entry, just for the purpose of exemplifying
│ ├ paketo-buildpacks/bellsoft-liberica@7.0.0
│ ├ paketo-buildpacks/gradle@4.0.0 (optional)
│ ├ paketo-buildpacks/leiningen@2.0.0 (optional)
│ ├ paketo-buildpacks/maven@4.0.0 (optional)
│ ├ paketo-buildpacks/sbt@4.0.0 (optional)
│ ├ paketo-buildpacks/executable-jar@4.0.0 (optional)
│ ├ paketo-buildpacks/apache-tomcat@4.0.0 (optional)
│ ├ paketo-buildpacks/dist-zip@3.0.0 (optional)
│ ├ paketo-buildpacks/spring-boot@4.0.0 (optional)
│ ├ paketo-buildpacks/procfile@4.0.0 (optional)
│ ├ paketo-buildpacks/azure-application-insights@4.0.0 (optional)
│ ├ paketo-buildpacks/debug@3.0.0 (optional)
│ ├ paketo-buildpacks/google-stackdriver@3.0.0 (optional)
│ ├ paketo-buildpacks/jmx@3.0.0 (optional)
│ ├ paketo-buildpacks/encrypt-at-rest@3.0.0 (optional)
│ ├ paketo-buildpacks/environment-variables@3.0.0 (optional)
│ └ paketo-buildpacks/image-labels@3.0.0 (optional)
I´m not sure if the above would be something that is possible to do with
would address somehow what we are looking for. While writing the above, I realized that there might be another alternative. To provide you more context, what we currently do is to build a container image from users source code, this via the |
@qu1queee Unfortunately the lifecycle does not currently support pulling in additional buildpacks (although we will add this feature eventually). And the existing paketo builder images do not contain JVM buildpacks other than Bellsoft Liberica. If you want a different JVM to be the default in your builder image you would need to create your own builder builder image that has a group containing the desired ordering of buildpacks. For example, from a
We do publish a composite buildpack
However, for any other distro you would need to compose the group from the full set of components. |
@ekcasey thanks for the information, it´s clear we will need to maintain our own builder image. Is there any documentation I could use as a reference for maintaining our own builder image and also to ensure we keep up-to-date with the paketo latest one. For example, where could I find the |
You can find the To use a different JVM buildpack, you can replace The full builder also contains the Java Native Image buildpack but this will only work with the GraalVM currently, so you can choose to leave it or remove it entire. If you like, you can use our pipeline-builder to keep your builder up to date with the latest buildpack. The pipeline builder should be well documented but not sure it has been used by many folks outside the Paketo Java buildpack team so please do let me know if you run into any issues. You can look at the projectriff builder for an example pipeline config. The paketo tiny/base/full builders don't actually use the pipeline-builder, but you could look at the GHA workflows in those repos for an alternate approach. |
@ekcasey great, thanks for this explanation. I think you can close this issue, the latest information should help us to keep a customized builder image from our side, up-to-date with the official paketo one. |
What happened?
Hello folks. I´m trying to understand if there is a way for me to swap the current Java distro embedded on a Builder image, in favor of something different than the default(Liberty?)
I´m expecting this to be easily swappable and to not force me to have the need of maintaining my own builder image.
Build Configuration
Im using tekton for building container images, and the paketo available
builder
image from upstream.I´m mainly interested here on Java.
I´using the latest builder, docker.io/paketobuildpacks/builder:full
Checklist
Please confirm the following:
The text was updated successfully, but these errors were encountered: