Buildpack looks for manifest even when binary is provided

[lanthoor]

Hi there,

I am building an image using a pre-built binary (jar file). The file is specified using the --path flag of pack CLI. The heroku jvm buildpack ignores it completely and looks for a manifest file (pom.xml/etc.). This results in no buildpack group passing detection and my image build fails. PFA the command and the logs.

$ pack build my/image:latest --path ./path/to/app.jar --env 'BP_JVM_VERSION=22.*' --env BP_JVM_TYPE=JRE --builder heroku/builder:24 --trust-builder --platform linux/arm64

===> ANALYZING
Restoring data for SBOM from previous image
===> DETECTING
======== Output: heroku/python@0.10.0 ========
No Python project files found (such as requirements.txt).
======== Results ========
fail: heroku/python@0.10.0
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/nodejs-engine@3.2.3
skip: heroku/nodejs-yarn@3.2.3
pass: heroku/jvm@6.0.0
pass: heroku/ruby@3.0.0
skip: heroku/procfile@3.1.1
Resolving plan... (try #1)
fail: heroku/nodejs-engine@3.2.3 provides unused node
Resolving plan... (try #2)
skip: heroku/nodejs-engine@3.2.3 provides unused node
skip: heroku/jvm@6.0.0 provides unused jdk
fail: heroku/ruby@3.0.0 provides unused ruby
======== Results ========
pass: heroku/nodejs-engine@3.2.3
fail: heroku/nodejs-corepack@3.2.3
fail: heroku/nodejs-pnpm-install@3.2.3
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/nodejs-engine@3.2.3
fail: heroku/nodejs-pnpm-engine@3.2.3
fail: heroku/nodejs-pnpm-install@3.2.3
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/nodejs-engine@3.2.3
skip: heroku/nodejs-corepack@3.2.3
fail: heroku/nodejs-yarn@3.2.3
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/nodejs-engine@3.2.3
skip: heroku/nodejs-corepack@3.2.3
skip: heroku/nodejs-npm-engine@3.2.3
fail: heroku/nodejs-npm-install@3.2.3
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/nodejs-engine@3.2.3
skip: heroku/procfile@3.1.1
Resolving plan... (try #1)
fail: heroku/nodejs-engine@3.2.3 provides unused node
Resolving plan... (try #2)
fail: heroku/nodejs-engine@3.2.3 provides unused node
======== Results ========
pass: heroku/jvm@6.0.0
fail: heroku/maven@6.0.0
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/jvm@6.0.0
fail: heroku/gradle@6.0.0
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/jvm@6.0.0
fail: heroku/sbt@6.0.0
skip: heroku/procfile@3.1.1
======== Results ========
pass: heroku/go@0.4.0
skip: heroku/procfile@3.1.1
Resolving plan... (try #1)
fail: heroku/go@0.4.0 provides unused go
======== Output: heroku/php@0.2.0 ========
No PHP project files found.
======== Results ========
fail: heroku/php@0.2.0
skip: heroku/procfile@3.1.1
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

Could you adjust the buildpack detection logic so that it doesn't look for a manifest file when the --path flag is specified to point to a jar/war?

[Malax]

Hi @lanthoor!

Thanks for letting us know about your use-case, appreciated! You're correct, this isn't supported out of the box currently.

The workaround for the current state of the builder would be adding a system.properties file next to your jar file with the following contents: java.runtime.version=22 and passing the directory with the jar and the system.properties to pack via --path. In addition, you'd need to specify the heroku/jvm buildpack explicitly.

In addition, this buildpack would not create a process for your single jar file automatically. You could use a Procfile (next to your jar and system.properties files) to configure the default process to run:

web: java -jar myjar.jar

This would be the command you're looking for:

pack build my/image:latest --path ./dir --builder heroku/builder:24 --trust-builder --platform linux/arm64 --buildpack heroku/jvm --buildpack heroku/procfile

I understand that this is much more elaborate than pointing pack to a jar file and have it just work. I'll leave this issue open and will update it over time as the situation improves for the use-case.

Let me know if the above works for you or if you encountered other obstacles, happy to help!