Description

The java-buildpack is a Cloud Foundry buildpack for running JVM-based applications. It is designed to run many JVM-based applications (Grails, Groovy, Java Main, Play Framework, Spring Boot, and Servlet) with no additional configuration, but supports configuration of the standard components, and extension to add custom components.

The cf-language-server-buildpack, based on java-buildpack, is a Cloud Foundry buildpack for running JVM-based language servers wrapper together with language servers adhering to the language server protocol. The language servers are supported by configuration of custom components providing download of software together with creation of configuration environment variables per language.

Requirements

There should be an available end point, org and space in CloudFoundry to deploy there the server as a Java application.

Usage

To use this buildpack specify the URI of the repository when pushing the language servers wrapper application to Cloud Foundry:

$ cf push <APP-NAME> -p <ARTIFACT> -b https://github.com/SAP/cf-language-server-buildpack.git

The language servers wrapper application for the push can be taken from: https://github.com/SAP/cloud-language-servers-container

Known Issues

• Each language server implementation is provided via component in the buildpack. It is currently not extensible from the outside.
• The configuration of each language server is based on enviroment variables which is a limited format.
• The location of the language server implementations to be downloaded by the buildpack is not final.

Configuration and Extension

The buildpack default configuration can be overridden with an environment variable matching the configuration file you wish to override minus the .yml extension. It is not possible to add new configuration properties and properties with nil or empty values will be ignored by the buildpack (in this case you will have to extend the buildpack, see below). The value of the variable should be valid inline yaml, referred to as "flow style" in the yaml spec (Wikipedia has a good description of this yaml syntax).

There are two levels of overrides: operator and application developer.

• If you are an operator that wishes to override configuration across a foundation, you may do this by setting environment variable group entries that begin with a prefix of JBP_DEFAULT.
• If you are an application developer that wishes to override configuration for an individual application, you may do this by setting environment variables that begin with a prefix of JBP_CONFIG.

Here are some examples:

Operator

1. To change the default version of Java to 11 across all applications on a foundation.

$ cf set-staging-environment-variable-group '{"JBP_DEFAULT_OPEN_JDK_JRE":"{jre: {version: 11.+ }}"}'

2. To change the default repository root across all applications on a foundation. Be careful to ensure that your JSON is properly escaped.

$ cf set-staging-environment-variable-group '{"JBP_DEFAULT_REPOSITORY": "{default_repository_root: \"http://repo.example.io\" }"}'

3. To change the default JVM vendor across all applications on a foundation. Be careful to ensure that your JSON is properly escaped.

$ cf set-staging-environment-variable-group '{"JBP_DEFAULT_COMPONENTS": "{jres: [\"JavaBuildpack::Jre::ZuluJRE\"]}"}'

Application Developer

1. To change the default version of Java to 11 and adjust the memory heuristics then apply this environment variable to the application.

$ cf set-env my-application JBP_CONFIG_OPEN_JDK_JRE '{ jre: { version: 11.+ }, memory_calculator: { stack_threads: 25 } }'

2. If the key or value contains a special character such as : it should be escaped with double quotes. For example, to change the default repository path for the buildpack.

The resources folder should contain any resources that should be part of the container when it is created for the use of the specific language server such as execution scripts, configuration files, etc'. For example see: language_server_bin_exec_jdt.

3. If the key or value contains an environment variable that you want to bind at runtime you need to escape it from your shell. For example, to add command line arguments containing an environment variable to a Java Main application.

$ cf set-env my-application JBP_CONFIG_JAVA_MAIN '{ arguments: "--server.port=9090 --foo=bar" }'

4. An example of configuration is to specify a javaagent that is packaged within an application.

$ cf set-env my-application JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf'

5. Environment variable can also be specified in the applications manifest file. For example, to specify an environment variable in an applications manifest file that disables Auto-reconfiguration.

env:
  JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '{ enabled: false }'

6. This final example shows how to change the version of Tomcat that is used by the buildpack with an environment variable specified in the applications manifest file.

env:
  JBP_CONFIG_TOMCAT: '{ tomcat: { version: 8.0.+ } }'

Phase 3 - deploy to CF

1. Go to Jass Project ls_buildpack_deploy : https://gkemonaco.jaas-gcp.cloud.sap.corp/job/lsp_deploy_buidpack/
2. Press Build with Parameters and fill in the parameters.
3. Press build and wait to see that the build succeeded.
4. You can enter your space in cf and check that {APP_NAME}-{your version} was deployed.

To learn how to configure various properties of the buildpack, follow the "Configuration" links below.

The buildpack supports extension through the use of Git repository forking. The easiest way to accomplish this is to use GitHub's forking functionality to create a copy of this repository. Make the required extension changes in the copy of the repository. Then specify the URL of the new repository when pushing Cloud Foundry applications. If the modifications are generally applicable to the Cloud Foundry community, please submit a pull request with the changes. More information on extending the buildpack is available here.

Additional Documentation

• Design
• Security
• Standard Containers
  • Dist ZIP
  • Groovy (Configuration)
  • Java Main (Configuration)
  • Play Framework
  • Ratpack
  • Spring Boot
  • Spring Boot CLI (Configuration)
  • Tomcat (Configuration)
• Standard Frameworks
  • AppDynamics Agent (Configuration)
  • AspectJ Weaver Agent (Configuration)
  • Checkmarx IAST Agent (Configuration)
  • Client Certificate Mapper (Configuration)
  • Container Customizer (Configuration)
  • Container Security Provider (Configuration)
  • Contrast Security Agent (Configuration)
  • DataDog (Configuration
  • Debug (Configuration)
  • Elastic APM Agent (Configuration)
  • Dynatrace SaaS/Managed OneAgent (Configuration)
  • Google Stackdriver Debugger (Configuration)
  • Google Stackdriver Profiler (Configuration)
  • Introscope Agent (Configuration)
  • JaCoCo Agent (Configuration)
  • Java Memory Assistant (Configuration)
  • Java Options (Configuration)
  • JProfiler Profiler (Configuration)
  • JRebel Agent (Configuration)
  • JMX (Configuration)
  • Luna Security Provider (Configuration)
  • MariaDB JDBC (Configuration) (also supports MySQL)
  • Multiple Buildpack
  • Metric Writer (Configuration)
  • New Relic Agent (Configuration)
  • PostgreSQL JDBC (Configuration)
  • ProtectApp Security Provider (Configuration)
  • Riverbed AppInternals Agent (Configuration)
  • Sealights Agent (Configuration)
  • Seeker Security Provider (Configuration)
  • Spring Auto Reconfiguration (Configuration)
  • Spring Insight
  • SkyWalking Agent (Configuration)
  • Takipi Agent (Configuration)
  • YourKit Profiler (Configuration)
• Standard JREs
  • Azul Zulu (Configuration)
  • Azul Platform Prime (Configuration)
  • GraalVM (Configuration)
  • IBM® SDK, Java™ Technology Edition (Configuration)
  • OpenJDK (Configuration)
  • Oracle (Configuration)
  • SapMachine (Configuration)
• Extending
  • Application
  • Droplet
  • BaseComponent
  • VersionedDependencyComponent
  • ModularComponent
  • Caches (Configuration)
  • Logging (Configuration)
  • Repositories (Configuration)
  • Utilities
• Debugging the Buildpack
• Buildpack Modes
• Related Projects
  • Java Buildpack Dependency Builder
  • Java Buildpack Memory Calculator
  • Java Test Applications
  • Java Buildpack System Tests
  • jvmkill

Building Packages

The buildpack can be packaged up so that it can be uploaded to Cloud Foundry using the cf create-buildpack and cf update-buildpack commands. In order to create these packages, the rake package task is used.

Note that this process is not currently supported on Windows. It is possible it will work, but it is not tested, and no additional functionality has been added to make it work.

Online Package

The online package is a version of the buildpack that is as minimal as possible and is configured to connect to the network for all dependencies. This package is about 250K in size. To create the online package, run:

$ bundle install
$ bundle exec rake clean package
...
Creating build/java-buildpack-cfd6b17.zip

Offline Package

The offline package is a version of the buildpack designed to run without access to a network. It packages the latest version of each dependency (as configured in the config/ directory) and disables remote_downloads. To create the offline package, use the OFFLINE=true argument:

To pin the version of dependencies used by the buildpack to the ones currently resolvable use the PINNED=true argument. This will update the config/ directory to contain exact version of each dependency instead of version ranges.

$ bundle install
$ bundle exec rake clean package OFFLINE=true PINNED=true
...
Creating build/java-buildpack-offline-cfd6b17.zip

If you would rather specify the exact version to which the buildpack should bundle, you may manually edit the config/ file for the component and indicate the specific version to use. For most components, there is a single version property which defaults to a pattern to match the latest version. By setting the version property to a fixed version, the buildpack will install that exact version when you run the package command. For JRE config files, like config/open_jdk_jre.yml, you need to set the version_lines array to include the specific version you'd like to install. By default, the version_lines array is going to have a pattern entry for each major version line that matches to the latest patch version. You can override the items in the version_lines array to set a specific versions to use when packaging the buildpack. For a JRE, the jre.version property is used to set the default version line and must match one of the entries in the version_lines property.

This package size will vary depending on what dependencies are included. You can reduce the size by removing unused components, because only packages referenced in the config/components.yml file will be cached. In addition, you can remove entries from the version_lines array in JRE configuration files, this removes that JRE version line, to further reduce the file size.

Additional packages may be added using the ADD_TO_CACHE argument. The value of ADD_TO_CACHE should be set to the name of a .yml file in the config/ directory with the .yml file extension omitted (e.g. sap_machine_jre). Multiple file names may be separated by commas. This is useful to add additional JREs. These additional components will not be enabled by default and must be explicitly enabled in the application with the JBP_CONFIG_COMPONENTS environment variable.

$ bundle install
$ bundle exec rake clean package OFFLINE=true ADD_TO_CACHE=sap_machine_jre,ibm_jre
...
Caching https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/8.0.6.26/linux/x86_64/ibm-java-jre-8.0-6.26-x86_64-archive.bin
Caching https://github.com/SAP/SapMachine/releases/download/sapmachine-11.0.10/sapmachine-jre-11.0.10_linux-x64_bin.tar.gz
...
Creating build/java-buildpack-offline-cfd6b17.zip

Package Versioning

Keeping track of different versions of the buildpack can be difficult. To help with this, the rake package task puts a version discriminator in the name of the created package file. The default value for this discriminator is the current Git hash (e.g. cfd6b17). To change the version when creating a package, use the VERSION=<VERSION> argument:

$ bundle install
$ bundle exec rake clean package VERSION=2.1
...
Creating build/java-buildpack-2.1.zip

Packaging Caveats

1. Prior to version 4.51 when pinning versions, only the default JRE version is pinned. There is special handling to package additional versions of a JRE and the way this works, it will pick the latest version at the time you package not at the time of the version's release. Starting with version 4.51, the version number for all JRE version lines is tracked in the config/ file.

2. The index.yml file for a dependency is packaged in the buildpack cache when building offline buildpacks. The index.yml file isn't versioned with the release, so if you package an offline buildpack later after the release was tagged, it will pull the current index.yml, not the one from the time of the release. This can result in errors at build time if a user tells the buildpack to install the latest version of a dependency because the latest version is calculated from the index.yml file which has more recent versions than what are packaged in the offline buildpack. For example, if the user says give me Java 11._+ and the buildpack is pinned to Java 11.0.13_8 but at the time you packaged the buildpack the latest version in index.yml is 11.0.15_10 then the user will get an error. The buildpack will want to install 11.0.15_10 but it won't be present because 11.0.13_8 is all that's in the buildpack.

   Because of #1 for versions prior to 4.51, this only impacts the default JRE. Non-default JREs always package the most recent version, which is also the most recent version in index.yml at the time you package the offline buildpack. For 4.51 and up, this can impact all versions.

3. Because of #1 and #2, it is not possible to accurately reproduce packages of the buildpack, after releases have been cut. If building pinned or offline buildpacks, it is suggested to build them as soon as possible after a release is cut and save the produced artifact. Alternatively, you would need to maintain your own buildpack dependency repository and keep snapshots of the buildpack dependency repository for each buildpack release you'd like to be able to rebuild.

See #892 for additional details.

Running Tests

To run the tests, do the following:

$ bundle install
$ bundle exec rake

Running Cloud Foundry locally is useful for privately testing new features.

Contributing

Pull requests are welcome; see the contributor guidelines for details.

License

This buildpack is released under version 2.0 of the Apache License.