build-templates
build-templates copied to clipboard
knative
buildpack template does not build Java applications
The buildpacks template using the CF Java buildpack. This takes a JAR or WAR as input. You can either extract the contents of the JAR/WAR to /workspace, or you can set the PACK_APP_ZIP env var to the path to the JAR/WAR. (This works relative to /workspace.)
I'm unsure if that's on the roadmap for the CF Java buildpack. You could reach out to the folks that maintain it.
We do have a sample v3 buildpack for Java that supports source-based workflows. This should be usable with knative build after #45 is complete.
@saturnism It will be an option for deploying Java applications, but likely not the most common way to do it.
Over the years we've found that enterprise Java applications have lots of problems building in offline, containerized, environments (the traditional CF use-case). Between the need to go to repositories/proxies for plugins/dependencies that are available in CI environments but not in production environments, to the fact that many enterprise Java build agents are snowflakes that are difficult to replicate in CF, most customers prefer to build a compiled, complete Java artifact with their existing build infrastructure and push that from a repository. This will be the first use-case we'll be aiming to satisfy and then add building from source once that's solid.
agreed on the building locally. but it's also suboptimal to having to checking a JAR/WAR into git though. Reminds me of openshift days :)
There is already a way to build and push containers to knative. It would be nice if when it eventually is possible to send just a jar/war w/o having to check them in. Or, retrieving a versioned jar/war from a maven repository?
Pulling from a Maven repository (typically Artifactory) is definitely on our radar. It’s already the most common way to push to Cloud Foundry (CI pipeline pushes to Artifactory, subsequent steps always pull that artifact and push to appropriate testing locations) so it’s a target use-case.
nice! if we can have a shared build-step that can do the maven repository download, we can then also reuse it in a few different builders :D
@saturnism https://github.com/cloudfoundry/build-system-buildpack
The first cuts of both the riff-buildpack-group and the java-buildpack-group both contain this to optionally build from source.
how to use build-system-buildpack to build a image from source? i tried and i got the below error malformed buildpack does not contain a /bin dir: https://github.com/cloudfoundry/build-system-buildpack
@ctatineni The build-system-buildpack is built for use with Cloud Native Buildpacks and will not work straight out of the box with knative. There's a fair amount of work being done by Pivotal internally, as well as riff in order to bring the Cloud Native Buildpacks functionality to knative, but I don't think it's publicly available yet.
looks like the cnbuildpack is in and i tried to build from source: https://github.com/saturnism/catnotcat-function.git
After maven install, it displayed an error:
[build-step-build] [INFO] BUILD SUCCESS
[build-step-build] [INFO] ------------------------------------------------------------------------
[build-step-build] [INFO] Total time: 21.185 s
[build-step-build] [INFO] Finished at: 2019-03-20T11:16:55Z
[build-step-build] [INFO] ------------------------------------------------------------------------
[build-step-build] ++ find target -maxdepth 1 -name '*.jar' -type f
[build-step-build] + for jarFile in $(find target -maxdepth 1 -name "*.jar" -type f)
[build-step-build] + echo 'processes = [{ type = "web", command = "java -jar target/demo-function-0.0.1-SNAPSHOT.jar"}]'
[build-step-build] + break
[build-step-export] 2019/03/20 11:17:00 Error: failed to : metadata for previous image: unexpected end of JSON input
@saturnism try deleting the registry you are using for the image or use a new one, the buildpacks sometimes fail to read metadata from existing images
