Re: Java buildpack


Ben Hale <bhale@...>
 

The fundamental answer is timing. There is a very vocal contingent of users that dislikes how long it takes to stage applications. Today a typical Spring Boot staging takes well less than a minute[1] (depending on underlying performance) and is considered by some to be too long. Building a Java application regardless of whether you use Gradle or Maven requires the downloading of well, the universe. Beyond the dependencies used by an application, you also need to download the plugins that Maven requires. For an example of this, delete `~/.m2/repository` and then do a `./mvnw clean package` on your application. The elapsed time (many minutes, many megabytes downloaded) is what would be **added** to any staging as it currently exists today.

Obviously, this time doesn’t disappear. The penalty must be paid somewhere, but as an experience for CF, requiring that penalty to be paid once, in a CI/CD pipeline is more acceptable than paying it as part of staging. I’d assume that the same customers that are complaining that about Java application staging time today, would complain about Go applications requiring compilation during staging as that would result in even larger staging times.

There’s certainly an element of “same artifact, all environments” (the decision for this buildpack was made nearly four years ago[2], long before downloading and uploading droplets was possible) but the strongest reason is simply to minimize the amount of time staging an application that you likely already have complied as part of your CI/CD or local development.


-Ben Hale
Cloud Foundry Java Experience




[1]: 16.26s uncached on PWS

```
2017-03-15T13:09:13.83-0700 [STG/0] OUT Downloaded app package (21.5M)
2017-03-15T13:09:15.76-0700 [STG/0] OUT -----> Java Buildpack Version: 6b81853 | https://github.com/cloudfoundry/java-buildpack.git#6b81853
2017-03-15T13:09:16.54-0700 [STG/0] OUT -----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (0.5s)
2017-03-15T13:09:17.68-0700 [STG/0] OUT -----> Downloading Open JDK Like Memory Calculator 3.5.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.5.0_RELEASE.tar.gz (0.0s)
2017-03-15T13:09:17.64-0700 [STG/0] OUT Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.1s)
2017-03-15T13:09:18.40-0700 [STG/0] OUT Loaded Classes: 15348, Threads: 300, JAVA_OPTS: ''
2017-03-15T13:09:18.44-0700 [STG/0] OUT -----> Downloading Jvmkill Agent 1.4.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/trusty/x86_64/jvmkill-1.4.0_RELEASE.so (0.0s)
2017-03-15T13:09:18.49-0700 [STG/0] OUT -----> Downloading Container Certificate Trust Store 2.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-2.0.0_RELEASE.jar (0.0s)
2017-03-15T13:09:19.00-0700 [STG/0] OUT Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.5s)
2017-03-15T13:09:19.14-0700 [STG/0] OUT -----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (0.1s)
2017-03-15T13:09:30.09-0700 [STG/0] OUT Uploading droplet…
````

[2]: https://github.com/cloudfoundry/java-buildpack/commit/f65aa90e49d7c7799e27687246766d4e103a1bcc

On Mar 14, 2017, at 14:47, Søren Hansen <soren(a)linux2go.dk> wrote:

I've wondered for a while why the Java buildpack for Cloud Foundry doesn't actually build anything. Some (all?) the other buildpacks are just the Heroku ones with small changes, but the Java one is fundamentally different, and whereas the Heroku one accepts source code and builds it, the Cloud Foundry one expects built artifacts.. Why?

Best regards,
Soren.

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.