Mike, this is so buildpacks can be composed together.

For example, if a user want to use NodeJS to compile Javascript assets for
a Java app (yes, there always Maven support, but some have different work
flows).

Multi-buildpack doesn't alleviate forking of buildpacks. In my opinion,
the above proposals for extensions to the buildpack app life cycle
are orthogonal.


On Mon, Apr 11, 2016 at 10:44 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This seems to be yet another way to extend buildpacks with out forking to
go along with [0] and [1]. My only hope is that all these newly proposed
extension mechanisms come together in a simple, coherent, and extensible
way.

Mike

[0]
https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/pull/13
[1]
https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit#



On Sun, Apr 10, 2016 at 6:15 PM, Danny Rosen <drosen(a)pivotal.io> wrote:

Hi there,

The CF Buildpacks team is considering taking on a line of work to
provide more formal support for multibuildpacks. Before we start, we would
be interested in learning if any community users have compelling use cases
they could share with us.

For more information on multibuildpacks, see Heroku's documentation [1]

[1] -
https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app