With the recent addition of the cf create-buildpack and cf update-buildpack commands, we’ve been looking into changes to how the Java Buildpack is deployed on Cloud Foundry. There is a move afoot to remove the buildpacks from the DEAs in favor of using those commands (with an automated initial install to preserve user-experience) and an outcome of this was the need to more easily create ‘packaged’ buildpacks. In the process of delivering these packages we also realized that we could also deliver “offline” buildpacks. To understand why “offline” buildpacks are interesting, it helps to understand why the buildpack is designed to look for dependencies on the Internet in the first place.
Buildpacks are at the core of the Cloud Foundry architecture and we’ve recently made significant improvements to the Cloud Foundry Java Buildpack. As the lead developer of the buildpack, I’d like to give you some insight into the design principles behind it, how to use, configure, and extend it, and what the future holds.
The primary objective of the Java buildpack is to be the easiest way to run a Java application.1 The word easiest can mean a lot of things, but to me it means that a developer can push an application and have an “it just works™” experience. An application developer shouldn’t have to mess about with details like memory settings or configuring the container to work with a bound service.