The built-in CF buildpacks are submodules in the dea
If you are deploying your own CF, you can fork this repo and add whatever
buildpack subdirectories you would like to make them "native" to your CF
deployment. When an app is being staged, dea calls the "detect" script in
each known buildpack until one of them indicates that they know how to
handle the app (usually by detecting the existence of certain files that
are specific to the language/runtime/framework supported by the buildpack).
Custom buildpacks (unknown to the CF deployment) can be specified when an
app is pushed by providing a git URL to the buildpack as shown
In this case, dea clones the git repo on-demand and then uses it to stage
So, to answer your question, there is nothing inherent in dea itself -
everything is completely contained in either a set of known buildpacks or
the one buildpack specified with the push.
On Thursday, May 23, 2013 5:55:46 PM UTC-5, Michael Surkan wrote:
Does anyone know how contained the concept of NG build packs is? For
example, would it be possible for someone to publish a build pack for a
completely new language and framework with their application to an NG cloud
that had never hosted that framework before?
I am just trying to understand if there needs to be any inherent knowledge
about given frameworks or languages inherent in the DEAs or controllers
themselves or if everything can be completely contained within the