feat: added template for java binary builder

[rohansen856]

Summary

This PR introduces a JavaBinaryBuilder plugin following the same patterns and lifecycle as the existing GoBinaryBuilder.
The goal is to support Java repositories by producing a versioned .jar artifact that can be uploaded to GitHub Releases in a consistent way.

Currently implemented things

• Auto-detect build system: Maven (pom.xml) or Gradle (build.gradle / build.gradle.kts)

• JAR is the standard packaged output for Java projects and is the closest equivalent “release artifact” for this builder system, so the “binary” for Java is treated as a JAR (not a native ELF executable).

• Builds are executed inside Docker containers using the repo mounted into /app, as it ensures reproducible builds across dev machines + CI environments and follows the same execution model as the Go builder.

• the default Docker image is Maven + Temurin JDK 17 as Java 17 is a stable LTS choice and Maven is common. see: https://hub.docker.com/layers/library/maven/3.9-eclipse-temurin-17/images/sha256-078164c49b664077cd330ad6cd367eb3baa5188380d68c82bf364c04c11748e9

Questions before i finalize the PR

• What should "Java binary" mean for this system... plain jar or fat/uber jar
• when multiple jars exist, should we prioritize shaded jars / Spring Boot jars?

So, Once the above decisions are confirmed, I will update the builder into a finalized implementation and push the changes.
PS, I havent yet manually tested this on a java project, but will do thst once the code is ready.

cc @pleia2 @rposts

[rposts]

Thanks @rohansen856 for the PR.

• Fat JAR sounds reasonable for "Java binary" in both cases
• Provide an example of GH repo that can be built by this builder

[rohansen856]

@rposts done wil all the update. I also tested on a demo maven and gradle repo:

• for the maven repo i used this as an example project: https://github.com/spring-projects/spring-petclinic
• Ran the builder:

from builders.binary.java_binary_builder import JavaBinaryBuilder
builder = JavaBinaryBuilder()

repo_path = r"C:\Users\ASUS\Documents\work\opensource\spring-petclinic"
repo_gh_name = "spring-petclinic"

artifact = {
    "version": "test-1",
    # docker_image optional because Maven default is correct
}

out = builder.build(repo_path, repo_gh_name, artifact)
print("BUILT:", out)

• Output:

Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar (658 kB at 217 kB/s)
[INFO] Building jar: /app/target/spring-petclinic-4.0.0-SNAPSHOT.jar
[INFO] 
[INFO] --- spring-boot:4.0.1:repackage (repackage) @ spring-petclinic ---
[INFO] Replacing main artifact /app/target/spring-petclinic-4.0.0-SNAPSHOT.jar with repackaged archive, adding nested dependencies in BOOT-INF/.
[INFO] The original artifact has been renamed to /app/target/spring-petclinic-4.0.0-SNAPSHOT.jar.original
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  04:56 min
[INFO] Finished at: 2026-01-27T16:55:13Z
[INFO] ------------------------------------------------------------------------
BUILT: C:\Users\ASUS\Documents\work\opensource\spring-petclinic\build\spring-petclinic_test-1_s390x.jar

• tested on gradle project: https://github.com/gradle/gradle-build-scan-quickstart
• Ran the builder:

from builders.binary.java_binary_builder import JavaBinaryBuilder
builder = JavaBinaryBuilder()

repo_path = r"C:\Users\ASUS\Documents\work\opensource\gradle-build-scan-quickstart"
repo_gh_name = "gradle-build-scan-quickstart"
artifact = {"version": "gradle-test"}

out = builder.build(repo_path, repo_gh_name, artifact)
print("BUILT:", out)

• Output:

Starting a Gradle Daemon (subsequent builds will be faster)
Calculating task graph as no cached configuration is available for tasks: clean build
> Task :check UP-TO-DATE
> Task :clean
> Task :processResources NO-SOURCE
> Task :compileJava
> Task :classes
> Task :jar
> Task :assemble
> Task :build

BUILD SUCCESSFUL in 33s
3 actionable tasks: 3 executed

The Build Scan was not published due to a configuration problem.

The Gradle Terms of Use have not been agreed to.

For more information, please see https://gradle.com/help/gradle-plugin-terms-of-use.

Alternatively, if you are using Develocity, specify the server location.
For more information, please see https://gradle.com/help/gradle-plugin-config.

Configuration cache entry stored.
BUILT: C:\Users\ASUS\Documents\work\opensource\gradle-build-scan-quickstart\build\gradle-build-scan-quickstart_gradle-test_s390x.jar

So, All the build succeded.

[rohansen856]

Also Regarding running testcases to detect potential s390x-specific failures... I agree this is important, but I think it would be better handled in a separate follow up PR rather than this one.

For this PR, I intentionally kept the Java builder aligned with the existing Go builder (which also skips tests) to maintain consistency and keep the scope focused on artifact generation...

Adding test execution support would require some additional research from my side, and i would try to implement a similar approach for for both Go and Java builders together...

I am happy to explore and work on that once this builder interface is finalized...