Although, correct me if I'm wrong, this feature could be used as a
solution for some of those cases. For example, if my application depends
upon an oracle-service my node application will require the oracle binary
libraries to be configured in my environment before the nodejs buildpack
runs. If I create an "oracle-library" buildpack that installs the oracle
libraries in my staging container before npm install then this is
potentially another way to cover some of the use cases of the other
extension points right?

Mike

On Mon, Apr 11, 2016 at 3:38 PM, JT Archie <jarchie(a)pivotal.io> wrote:

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