feat: add s390x and ppc64le support

[Nachiket-Roy]

Summary

Updates package.toml to include target definitions for the s390x and ppc64le architectures.
rel : paketo-buildpacks/jammy-tiny-stack#257

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[dmikusa]

This is probably not something we can do until there are a large chunk of the underlying buildpacks that are in this composite buildpack also support the given architectures. The reason is that the buildpack wouldn't be functional on those architectures without those underly buildpacks also supporting it.

Is this something you'd be willing to help do?

[Nachiket-Roy]

This is probably not something we can do until there are a large chunk of the underlying buildpacks that are in this composite buildpack also support the given architectures. The reason is that the buildpack wouldn't be functional on those architectures without those underly buildpacks also supporting it.

Is this something you'd be willing to help do?

Yes, I would be happy to help add support to the underlying buildpacks. Could you provide a list of the specific underlying buildpacks that are blocking this PR? I can start looking into their repositories and see what needs to be updated.

[dmikusa]

@Nachiket-Roy - The list is in the README, see https://github.com/paketo-buildpacks/java#included-buildpacks. What's going to be challenging are the buildpacks that supply dependencies. We'll need to have dependencies for those buildpacks as well. Of those buildpacks, we'd need bellsoft or one of the jvm vendors, maven, gradle, tomcat, and syft. I'm not sure if we need to have every buildpack in that list supported, as some are optional and less frequently used. If we don't have support for one, we just need to make sure that the error is clear if someone were to try and use it on that platform.

[Nachiket-Roy]

@dmikusa I have added s390x and ppc64le support to Maven, Gradle, Apache-Tomcat, and Syft.
However, I ran into blockers with the BellSoft:

1. s390x: BellSoft does not appear to publish s390x binaries on their public API or GitHub releases.
2. ppc64le: BellSoft does publish ppc64le binaries, but the BellSoft API expects the architecture string ppc instead of ppc64le. We will need a small patch to that dependency action to map ppc64le -> ppc before the automated workflows will work.

[dmikusa]

@dmikusa I have added s390x and ppc64le support to Maven, Gradle, Apache-Tomcat, and Syft. However, I ran into blockers with the BellSoft:

1. s390x: BellSoft does not appear to publish s390x binaries on their public API or GitHub releases.

2. ppc64le: BellSoft does publish ppc64le binaries, but the BellSoft API expects the architecture string ppc instead of ppc64le. We will need a small patch to that dependency action to map ppc64le -> ppc before the automated workflows will work.

Thanks! I merged most of these, but left a note on Maven.

The long term answer to Bellsoft might be our effort with the jvm-vendors buildpack. This is essentially moving all the JVM vendors under one buildpack, so at that point, we could have jvm-vendors do a little logic to pick a different default for those two architectures, so it picked a default that is supported on that architecture. Is there a different JVM vendor you'd typically use?

That work is progressing, but it's a big change so it won't be something we can do immediately. We have to transition to it over some time.

Short term, it's tricky. That buildpack works through libjvm, and because of the jvm-vendors buildpack efforts I really was hoping to not need to cut any more libjvm releases, so code changes there are probably not an option.

Maybe there's something we could put directly into the Bellsoft buildpack though, a quick wrapper func or check prior to the libjvm code that just checks the architecture & prints an error mesage if you're on an unsupported architecture (i.e. s390x). We'd then need a different vendor that supports this architecture and we could tell people to use that vendor when on s390x for now, with jvm-vendors buildpack being the long term solution.

I think the other part is not an issue as we can set that in the metadata. The architecture that a user runs on needs to match the golang architecture because that's what containers use. If a vendor uses a different one, that's OK. That happened a lot with arm64 (golang arch) and aarch64 (what a lot of places call it). We just have to configure it right in the metadata. If you look for aarch64 in the pipeline-descriptory.yml / buildpacks.toml files, you can find an example of that.

Let me know if you have questions about that.

[Nachiket-Roy]

@dmikusa Thanks for the guidance! I've gone ahead and update the PRs. Let me know if there's anything else needed.