Hi Ryan,

Thanks for asking this question.

The "risk" called out in the inception encompassed a number of things, but what they really all boil down to is that the java-buildpacks team has its own roadmap and conventions; and the two teams don't often communicate about sharing resources, infrastructure, or planning.

I think a reasonable first step is for you and I (and maybe JT and Ben, the engineering anchors for each team) to have a regular chat on our calendars. I'd prefer not to get bitten by Conway's Law if we can easily mitigate this risk. I'll ship you a calendar invite; as well as make sure the java-buildpack team, as well as voting members of the PMC, are represented in the next inception or roadmap discussion.


On Mon, May 4, 2015 at 2:43 PM, Ryan Morgan <ryanmorgan@gmail.com> wrote:

Thanks for the update Mike.  Can we get a bit more detail on java-buildpack divergence from the other buildpacks?


On Mon, May 4, 2015 at 10:50 AM, Mike Dalessio <mdalessio@pivotal.io> wrote:
Hi all,

We held the first Buildpacks PMC meeting today; I'd like to share the agenda and notes.

For reference, all agendas notes for the Buildpacks PMC will be kept in a public Google Drive folder at this URL:

I realize GDrive isn't the most convenient medium for some in the CF community; I'd love to hear how we can better support transparency for everyone.

Please feel free to respond with comments and questions!




  • Chip Childers, Cloud Foundry Foundation

  • Mike Dalessio, Pivotal (PMC lead)

  • Christopher Ferriss, IBM

  • Michael Fraenkel, IBM

  • Mark Kropf, Pivotal

Recent Inception Report and Stated Goals

The Buildpacks core development team held a project inception on 2015-04-20, to gain a shared understanding of upcoming goals and tracks of work.


    • Expand supported ecosystem to include more languages & frameworks
    • Cloud Foundry ownership of Buildpacks
    • Leverage new primitives in Diego (“app lifecycle”)
    • Enable 3rd party extensions to the Developer experience
    • Enable application developer extensions to the Developer experience
    • Set patterns for creating new buildpacks and for extending the Developer experience
    • Generate clearer diagnostics during staging
    • Enable Operator ease of updating common dependencies
    • Keep the `bin/detect` experience: buildpacks should Just Work™
    • Exert more ownership over the rootfs
    • Binary buildpack support


    • java-buildpack is diverging quickly from the core buildpacks
    • Lack of deep experience in some ecosystems
    • Wide variety in implementations across buildpacks
    • rootfs: with great power comes great responsibility (e.g., security response)
    • tight coupling between buildpacks and rootfs
    • versioning between buildpacks and rootfs

Current Backlog and Priorities

See https://www.pivotaltracker.com/n/projects/1042066

Notable near-term goals:

  • staticfile-buildpack support in `cf-release`

  • binary buildpack (a.k.a. “null buildpack”) support in `cf-release`

  • ability to generate and test CF rootfs-specific binaries; and tooling for CF operators to do the same

Proposal: Buildpack Incubation Process

Discussion today for PMC input; a draft document will be circulated for comment to cf-dev@ mailing list after the meeting, in a separate thread.

cf-dev mailing list