Ability to modify the Java distro in the Builder Image about java

[qu1queee]

@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.

[emalm]

Hey, @nebhale @ekcasey @twoseat, any thoughts on this question? I believe he and other folks at IBM have been able to do something similar with the CF Java buildpack. Thanks!

[ekcasey]

@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 pack, you could:

pack build samples/jar --buildpack gcr.io/paketo-buidpacks/azul-zulu --buildpack paketo-buildpacks/java

to use Azul Zulu instead of Bellsoft Liberica JVM distro.

There is one caveat in that at the beginning of the paketo-buildpacks/java group we include https://github.com/paketo-buildpacks/ca-certificates. If you are using this buildpack to install additional CA certificates, it will run after the preprended buildpack and therefore the custom certificates will not be trusted during the JVM installation. The only way around this currently is to respecify the entire order of component buildpacks. However, the CNB project is looking into adding buildpack replace functionality to the buildpack order.

The existing JVM distro buildpacks are:

• Paketo Amazon Corretto Buildpack
• Paketo Azul Zulu Buildpack
• Paketo BellSoft Liberica Buildpack - Default
• Paketo Eclipse OpenJ9 Buildpack
• Paketo GraalVM Buildpack
• Paketo SapMachine Buildpack

[qu1queee]

Hi @ekcasey , thanks, let me take a look on your comment and I will reach back to you if needed.

[qu1queee]

@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 default JVM distro in the builder-image (e.g. paketobuildpacks/builder:full).

In your example, I think you are building a container image with a default builder image, which I´m assuming is predefined by running pack config default-builder paketobuildpacks/builder:full or another recommended builder image. What we are looking for is to have a builder image where the Paketo BellSoft Liberica Buildpack is not the default.

For example, if I trigger a pack inspect-builder paketobuildpacks/builder:full, for the group 9, I see the following:

 ├ Group #9:
 │  └ paketo-buildpacks/[email protected]
 │     └ Group #1:
 │        ├ paketo-buildpacks/[email protected]               (optional)
 │        ├ paketo-buildpacks/[email protected]
 │        ├ paketo-buildpacks/[email protected]                        (optional)
 │        ├ paketo-buildpacks/[email protected]                     (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]                (optional)
 │        ├ paketo-buildpacks/[email protected]                 (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]                   (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]    (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]            (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]               (optional)
 │        ├ paketo-buildpacks/[email protected]         (optional)
 │        └ paketo-buildpacks/[email protected]                  (optional)

based on what you mentioned, what we would expect to see on the inspect, is something like:

 ├ Group #9:
 │  └ paketo-buildpacks/[email protected]
 │     └ Group #1:
 │        ├ paketo-buildpacks/[email protected]               (optional)
 │        ├ paketo-buildpacks/[email protected]                   <------ this is a fake entry, just for the purpose of exemplifying
 │        ├ paketo-buildpacks/[email protected]
 │        ├ paketo-buildpacks/[email protected]                        (optional)
 │        ├ paketo-buildpacks/[email protected]                     (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]                (optional)
 │        ├ paketo-buildpacks/[email protected]                 (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]                   (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]    (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]            (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]               (optional)
 │        ├ paketo-buildpacks/[email protected]         (optional)
 │        └ paketo-buildpacks/[email protected]                  (optional)

I´m not sure if the above would be something that is possible to do with pack(I´m assuming is not the case). I´m wondering if what you mentioned:

However, the CNB project is looking into adding buildpack replace functionality to the buildpack order.

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 /cnb/lifecycle/creator binary, available in paketobuildpacks/builder:full. You can see an example of one of our containers in sample. Do you know if the /cnb/lifecycle/creator could do the "swapping" ? it seems it support a -buildpacks flag, but is looking for a directory.

[ekcasey]

@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 builder.toml with the following group

[[order]]
group = [

### Order is strictly enforced
  { id = "paketo-buildpacks/ca-certificates",            version="2.0.0", optional = true },
  { id = "paketo-buildpacks/azul-zulu",                  version="7.0.0" },
  { id = "paketo-buildpacks/gradle",                     version="4.0.0", optional = true },
  { id = "paketo-buildpacks/leiningen",                  version="2.0.0", optional = true },
  { id = "paketo-buildpacks/maven",                      version="4.0.0", optional = true },
  { id = "paketo-buildpacks/sbt",                        version="4.0.0", optional = true },

### Order determines precedence
  { id = "paketo-buildpacks/executable-jar",             version="4.0.0", optional = true },
  { id = "paketo-buildpacks/apache-tomcat",              version="4.0.0", optional = true },
  { id = "paketo-buildpacks/dist-zip",                   version="3.0.0", optional = true },
  { id = "paketo-buildpacks/spring-boot",                version="4.0.0", optional = true },
  { id = "paketo-buildpacks/procfile",                   version="4.0.0", optional = true },

### Order does not matter
  { id = "paketo-buildpacks/azure-application-insights", version="4.0.0", optional = true },
  { id = "paketo-buildpacks/debug",                      version="3.0.0", optional = true },
  { id = "paketo-buildpacks/google-stackdriver",         version="3.0.0", optional = true },
  { id = "paketo-buildpacks/jmx",                        version="3.0.0", optional = true },

### Order is strictly enforced
  { id = "paketo-buildpacks/encrypt-at-rest",            version="3.0.0", optional = true },
  { id = "paketo-buildpacks/environment-variables",      version="3.0.0", optional = true },
  { id = "paketo-buildpacks/image-labels",               version="3.0.0", optional = true },
]

We do publish a composite buildpack paketo-buildpacks/java-azure containing Azul Zulu specifically, allowing for the simpler

[[order]]
group = [
  { id = "paketo-buildpacks/java-zure",                  version="5.0.0" },
]

However, for any other distro you would need to compose the group from the full set of components.

[qu1queee]

@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 builder.toml definition used for paketobuildpacks/builder:full ? . Anything that could help us is more than welcome :)

[ekcasey]

@qu1queee

You can find the builder.toml for the full builder here.

To use a different JVM buildpack, you can replace paketo-buildpacks/java with the expanded order definition (replacing the bellsoft liberica buildpack with your chosen distro).

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.