与service broker相比，buildpack的实务操作就容易多了，单就通用概念来说，其实用不着单写一篇，但是处女座强迫症发作，所以还是写一下，使CF这个框架对外扩展的两个维度（代码使用的服务和代码运行的环境）是完整的。这篇主要会写buildpack的基本实现逻辑，然后举三个需要修改buildpack的需求，进行实际操作描述。
基本原理
CF运行应用的基本过程是将用户发布的应用程序包解压开，然后将自己的所有buildpack拿来，按照指定顺序与程序包进行匹配，直到找到第一个能够运行这些代码的buildpack，然后将buildpack也解开，与这些应用代码打成一个包（即droplet），在按照指定的运行环境参数生成容器，将droplet扔进去，按照buildpack指定的启动命令，启动应用。在上面的过程中，buildpack实现了三步功能：
第一步，detect：检查当前应用程序包是否能够用本buildpack支持运行，比如，java buildpack发现WEB-INF路径就认为自己能够运行它。
第二步，compile：将应用程序包与buildpack包水乳交融一下，比如将java程序包放到tomcat的应用目录下，然后替换某些参数，比如将当前dea里的随机端口赋予这个tomcat实例。
第三部，release：将droplet启动，比如运行tomcat的startup.sh。
任何一个buildpack都有一个bin路径，放着三个指定名字（detect、compile、release）的脚本（任何dea的os能执行的脚本都可以），然后具体的实现逻辑就从这里触发了。下面将以java buildpack为例，通过三个实际需求，介绍buildpack的开发和使用。