Quick update on the TomEE Buildpack effort. We now have a git repository : https://github.com/cloudfoundry-community/tomee-buildpack.git <https://github.com/cloudfoundry-community/tomee-buildpack.git> and a slack channel https://cloudfoundry.slack.com/messages/tomee-buildpack/ <https://cloudfoundry.slack.com/messages/tomee-buildpack/> to discuss design and implementation details. The TomEE buildpack will be separate from the default java buildpack. The TomEE buildpack like the JBOSS and WebLogic buildpack will merge upstream changes automatically from the java buildpack.
/The following design and implementation principles will hold true for the TomEE buildpack./ - TomEE BP will follow the mechanism of extension[REFERENCE] laid down by the java BP. i.e. TomEE support will be introduced via a container like tomcat and java-main see https://github.com/cloudfoundry/java-buildpack/blob/master/README.md#configuration-and-extension on details of how to configure and extend the java buildpack. The TomEE buildpack will replace or disable the Tomcat container. - TomEE buildpack will setup TomEE to run enterprise java apps. This primarily entails packaging the buildpack acquiring TomEE binaries in the compile phase and setting up the droplet start command in the release phase. Given the sophisticated abstractions of droplet and application_root already in place with the java BP we expect the TomEE changes to be restricted to one file i.e. the tomee.rb. The TomEE BP will accept and run both ear and war files. http://tomee.apache.org/deploying-in-tomee.html The TomEE BP will need to be explicitly targeted by the cf push -b option when pushing a war file since the Java BP gets first dibs at staging and running the app by default. - A CI pipeline will need to be established for the TomEE buildpack. This could involve using Concourse <https://github.com/starkandwayne/concourse-tutorial> or Travis <https://travis-ci.org/cloudfoundry> . TomEE comes with an excellent portfolio <http://tomee.apache.org/examples-trunk/> of examples that can be used to validate feature/function of the buildpack and document any constraints. We are actively looking for volunteers. We desire a single squashed commit. Each commit is a discrete unit of work, to be understood together in it’s entirety. Seeing a single commit that embodies the entire functionality of the component makes reviewing and merging easier. also you will have a CLA on file to submit contributions. https://www.cloudfoundry.org/contribute/ *REFERENCE*: The Java buildpack is designed for extension in terms of adding adding agents, frameworks and containers. Documentation for extending the buildpack can be found here <https://github.com/cloudfoundry/java-buildpack#additional-documentation> . Extension of the buildpack is designed in such a way that it is trivial consume upstream changes to the buildpack, keeping forks up to date. The buildpack is designed so that all extensions should be _additive only_. Most extensions should not need to mutate any part of the buildpack; the buildpack is implemented as a collection of extensions -- View this message in context: http://tomee-openejb.979440.n4.nabble.com/Request-for-a-TomEE-Buildpack-tp4675612p4676480.html Sent from the TomEE Dev mailing list archive at Nabble.com.
