FAQ
As a proof-of-concepts, I'm trying to add support for the
jonas<http://jonas.ow2.org/>JEE container into the java-buildpack. I'm
only at the
beginning<https://github.com/Orange-OpenSource/java-buildpack/commits/master>,
yet the framework has been very useful so far. So ealy feedback though:

1) integration tests

I love the rspec-based unit tests in that they provide readeable specs and
good unit tests. However, I experience they are not sufficient to ensure
the buildpack quality, and need to be completed with manual app push, or
automated integrated tests. Part of the yeti tests used to provide such
coverage, by asserting the contract between the buildpack and the app
(using a sample app exposing a REST API invoked by asserts)

https://github.com/cloudfoundry/vcap-yeti/blob/58756e893f88f1779da1273a921d01e2af320be2/old_services_spec/canonical/java_spring_spec.rb

It would be great to encourage buildpack authors to contribute such
integration tests, and leverage a framework such as yeti for this as part
of the buildpack development. As an analogy, some
recipes<https://github.com/opscode-cookbooks/mysql/blob/master/TESTING.md>the
chef community seem to provide such
framework <https://github.com/opscode/test-kitchen>


2) developping buildpack using native target language

As a java developper extending the javabuild-pack, I'm tempted to reuse the
java-based code base such as vcap-java or containers java-based SDKs. With
the VCAP_SERVICES being planned to be exposed to buildpacks, this would
even make more sense. This may also reduce barrier to entry to have rich
buildpacks being developped for specific languages/frameworks. On the other
hand, sharing some common ruby-based infrastructure along languages is also
important.

Would there be a way to invoke java code as part of the buildpacks ? Would
http://rjb.rubyforge.org/ help ?

Thanks in advance,

Guillaume.

---
On Wednesday, July 3, 2013 9:03:32 AM UTC+2, Ben Hale wrote:
We welcome any and all feedback about the new buildpack as we're need to
understand how users are _actually_ using Java on Cloud Foundry.


-Ben Hale
Cloud Foundry Java Experience

Search Discussions

  • Ben Hale at Jul 9, 2013 at 10:15 am

    It would be great to encourage buildpack authors to contribute such
    integration tests, and leverage a framework such as yeti for this as part
    of the buildpack development. As an analogy, some recipes<https://github.com/opscode-cookbooks/mysql/blob/master/TESTING.md>the chef community seem to provide such
    framework <https://github.com/opscode/test-kitchen>
    This is absolutely a known concern for us. As of now, we've shied away from
    the yeti's as they simply take too much time to execute and don't fit well
    into our development cycle. The plan as it stands now is two-pronged:

    1. We're going to be adding integration tests and the support to run
    either locally or in TravisCI. We'll want this kind of test to be
    submitted along with unit tests for any external contribution. This is our
    main avenue for ensuring that the buildpack is going to work without a
    manual push.
    2. We're going to be filling out the 'official' yetis that run as part
    Cloud Foundry's builds to ensure that changes there are not _likely_ to
    break the buildpack. The applications in these yetis are not going to be
    full featured but rather are going to document and test our assumptions
    about the buildpack contract (since it's not well documented) to ensure
    that changes in Cloud Foundry don't break us without warning. This kind of
    test isn't going to be required of external contributions.

    2) developping buildpack using native target language

    As a java developper extending the javabuild-pack, I'm tempted to reuse
    the java-based code base such as vcap-java or containers java-based SDKs.
    With the VCAP_SERVICES being planned to be exposed to buildpacks, this
    would even make more sense. This may also reduce barrier to entry to have
    rich buildpacks being developped for specific languages/frameworks. On the
    other hand, sharing some common ruby-based infrastructure along languages
    is also important.

    Would there be a way to invoke java code as part of the buildpacks ? Would
    http://rjb.rubyforge.org/ help ?
    We debated quite a bit about this and in the end, native target language
    support will not be a goal for us. As we view it, the language of
    buildpacks (at least of this buildpack) is Ruby and to work on buildpacks,
    you'll need to learn at least a little bit of it. Ruby is an excellent
    language for working with buildpack concerns (filesystem access, UNIX
    command execution, etc.) and it's what we're putting all of our weight
    behind. Accessing Cloud Foundry infrastructure (like $VCAP_SERVICES) is
    possible using vcap-ruby and if that isn't complete or up today, the focus
    should be on improving that rather than adding support for other languages.

    One thing I am interested in is your mention of container's Java-based
    SDKs. What exactly do you plan on calling as part of the _buildpack
    lifecycle_ that falls into this category?

    -Ben Hale
    Cloud Foundry Java Experience

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedJul 8, '13 at 10:33a
activeJul 9, '13 at 10:15a
posts2
users2

2 users in discussion

Guillaume Berche: 1 post Ben Hale: 1 post

People

Translate

site design / logo © 2021 Grokbase