Java Buildpack v2.1

332 views
Skip to first unread message

Ben Hale

unread,
Apr 15, 2014, 5:19:52 AM4/15/14
to vcap...@cloudfoundry.org
I'm pleased to announce the release of the java-buildpack, version 2.1. This one took quite a while to get out there, but is packed with a lot of features that I'm sure you'll love. Some of the highlights are:
For a more detailed look at the changes in 2.1, please take a look at the commit log. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release.

I'm also pleased to announce the first release of the jboss-buildpack, version 2.1. This first release replaces the Tomcat container with the JBoss AS 7 container.  For a more detailed look at the differences between the java-buildpack and the jboss-buildpack, please take a look at this comparison. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release.

We're currently sorting out how updates to the Java Buildpack are going be handled on https://run.pivotal.io, so there will be a delay until this new version is the default buildpack there.  You can track the progress of this update using cloudfoundry/cf-release#352.  Once the update has happened, you'll also be able to tell using the fancy new version description that the buildpack writes out:

-----> Downloading Open Jdk JRE 1.7.0_51 from http://download.run.pivotal.io/openjdk/mountainlion/x86_64/openjdk-1.7.0_51.tar.gz (found in cache)
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (0.4s)
-----> Downloading Spring Auto Reconfiguration 0.8.7 from http://download.run.pivotal.io/auto-reconfiguration/auto-reconfiguration-0.8.7.jar (found in cache)
       Modifying /WEB-INF/web.xml for Auto Reconfiguration
-----> Downloading Tomcat Instance 7.0.53 from http://download.run.pivotal.io/tomcat/tomcat-7.0.53.tar.gz (found in cache)
       Expanding Tomcat to .java-buildpack/tomcat (0.0s)
-----> Downloading Tomcat Lifecycle Support 2.1.0_RELEASE from http://download.run.pivotal.io/tomcat-lifecycle-support/tomcat-lifecycle-support-2.1.0_RELEASE.jar (found in cache)
-----> Downloading Tomcat Logging Support 2.1.0_RELEASE from http://download.run.pivotal.io/tomcat-logging-support/tomcat-logging-support-2.1.0_RELEASE.jar (found in cache)


-Ben Hale
Cloud Foundry Java Experience

David Laing

unread,
Apr 15, 2014, 5:42:57 AM4/15/14
to vcap-dev
+1

Encouraging to see all the community contributions!

Thanks for all the hard work!


To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.



--
David Laing
Trading API @ City Index
da...@davidlaing.com
http://davidlaing.com
Twitter: @davidlaing

Dr Nic Williams

unread,
Apr 15, 2014, 9:34:13 AM4/15/14
to vcap...@cloudfoundry.org, vcap-dev
"We're currently sorting out how updates to the Java Buildpack are going be handled on https://run.pivotal.io


What do you mean? Has something changed or need to change?

Cornelia Davis

unread,
Apr 15, 2014, 9:50:09 AM4/15/14
to vcap...@cloudfoundry.org
Awesome Ben! Love the session-state caching!!

Ben Hale

unread,
Apr 15, 2014, 9:54:22 AM4/15/14
to vcap...@cloudfoundry.org
"We're currently sorting out how updates to the Java Buildpack are going be handled on https://run.pivotal.io


What do you mean? Has something changed or need to change?

Recently there's been an effort to move the buildpacks off of the DEAs (which is what led to the packaged buildpacks effort).  This is more or less done, but they haven't moved far; the submodules are now in cf-release instead of dea_ng.  This is certainly an improvement because, as BOSH deployed artifacts, they can be updated out of band with the DEAs.  They are, however, still tied to the lifecycle of Cloud Foundry itself.  This means that upgrades to the Java Buildpack are still tied to the multi-week PR cycle, and then gated by a release of Cloud Foundry.  With the advent of admin buildpacks and the create-buildpack/update-buildpack commands, there's no reason that this needs to be true.

I understand the need for the BOSH packages (the out-of-the-box experience is much improved if you don't have to manually install a bunch of extra bits), but there's no reason that https://run.pivotal.io can't simply do an update-buildpack with the newly released bits, the day that they are released.   We run a continuous (every two hours) system test of the Java Buildpack master (and a couple of other commercial forked buildpacks) against https://run.pivotal.io, so I have quite a lot of confidence in an upgrade as soon as a release is done.  I'd like to see https://run.pivotal.io getting our releases ASAP so that I can continue shrinking down the iteration cycle time, and getting community feedback on the changes.

Just to note, I'm not saying this won't happen.  It's more that since the Java Buildpack is the first one to get to this point, we're exploring new territory and discussions are ongoing.

Ben Hale

unread,
Apr 15, 2014, 9:57:35 AM4/15/14
to vcap...@cloudfoundry.org
Awesome Ben! Love the session-state caching!!

Make sure that you use it wisely.  As in the case of all shared state, it has the potential to destroy application performance and scalability.

Dr Nic Williams

unread,
Apr 15, 2014, 10:16:48 AM4/15/14
to vcap...@cloudfoundry.org, vcap...@cloudfoundry.org
Ok your release is coupled to cf-releases like normal but you're hoping to be able to deliver them independently in future.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Ben Hale

unread,
Apr 15, 2014, 10:22:39 AM4/15/14
to vcap...@cloudfoundry.org
Ok your release is coupled to cf-releases like normal but you're hoping to be able to deliver them independently in future.

Exactly.  Faster feedback on https://run.pivotal.io leads to better results for everyone else downstream.

James Bayer

unread,
Apr 16, 2014, 1:27:55 AM4/16/14
to vcap...@cloudfoundry.org
great job everyone with the community contributions! it's very cool to see all of those interactions and the result. looking at the tomcat logging issue in particular required a lot of back and forth, investigation and finally it resulted in a great configurable solution. thanks to all involved and especially to ben for his stewardship of the java buildpack!


To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.



--
Thank you,

James Bayer

kritee...@gmail.com

unread,
May 20, 2014, 1:17:17 AM5/20/14
to vcap...@cloudfoundry.org

Hi,
I am trying to build an offline buildpack and upload it to my CF PaaS(installed using CF Nise installer) so that my CF wont need internet when i push my Java webapp.

Bundler version: 1.6.2
Ruby version: ruby 1.9.3p545 (2014-02-24) [i386-mingw32]

i cloned this repo, did a 'bundle install', followed by 'bundle exec rake package OFFLINE=true'. i am getting the following error:

C:\Users\kjhawar\ws\java-buildpack>bundle exec rake package OFFLINE=true > log
.txt
The system cannot find the path specified.
The system cannot find the path specified.
[DownloadCache] WARN Request failure 1, retrying: Content has
invalid size. Was 4041, should be 3976.
[DownloadCache] WARN Request failure 2, retrying: Content has
invalid size. Was 4041, should be 3976.
[DownloadCache] WARN Request failure 3, retrying: Content has
invalid size. Was 4041, should be 3976.
[DownloadCache] WARN Request failure 4, retrying: Content has
invalid size. Was 4041, should be 3976.
[DownloadCache] WARN Request failure 5, retrying: Content has
invalid size. Was 4041, should be 3976.
[InternetAvailability] WARN Internet availability set to false: Reque
st failed: Content has invalid size. Was 4041, should be 3976.
[DownloadCache] WARN Unable to download http://download.run.pi
votal.io/groovy/index.yml into cache build/staging/resources/cache: Content has
invalid size. Was 4041, should be 3976.
rake aborted!
Unable to find cached file for http://download.run.pivotal.io/groovy/index.yml
C:/Users/kjhawar/ws/java-buildpack/lib/java_buildpack/util/cache/download_cache.
rb:65:in get' C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:144:inbloc
k (2 levels) in uris'
C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:141:in each ' C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:141:inbloc
k in uris'
C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:140:in each ' C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:140:inuris
'
C:/Users/kjhawar/ws/java-buildpack/rakelib/dependency_cache_task.rb:42:in initi alize' C:/Users/kjhawar/ws/java-buildpack/Rakefile:40:innew'
C:/Users/kjhawar/ws/java-buildpack/Rakefile:40:in `'
(See full trace by running task with --trace)

James Bayer

unread,
May 20, 2014, 9:39:49 AM5/20/14
to vcap...@cloudfoundry.org
turns out that krittee and ben are troubleshooting this with a github issue [1] on the java-buildpack repo.



--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/e2e9c865-fb95-4e85-b083-70dd10f0a9c6%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Reply all
Reply to author
Forward
0 new messages