Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Self-downloading binaries, properties files #317

Merged
merged 1 commit into from
Oct 26, 2015
Merged

Self-downloading binaries, properties files #317

merged 1 commit into from
Oct 26, 2015

Conversation

micha
Copy link
Contributor

@micha micha commented Oct 26, 2015

Fixes #229
Fixes #300

Properties Files

  • Boot now supports specifying any env var (eg. BOOT_VERSION) from
    properties files.

  • Setting BOOT_VERSION and BOOT_CLOJURE_VERSION is no longer required.

  • System properties are now supported in addition to properties files
    and environment variables.

  • Settings will be merged in the following order:

    1. BOOT_HOME/cache/boot.properties (deprecated)
    2. BOOT_HOME/boot.properties
    3. /boot.properties
    4. CWD/boot.properties
    5. environment variables
    6. system properties

    For example:

    CWD/boot.properties settings override BOOT_HOME/boot.properties,
    environment variables override all properties files, and system
    properties override everything else.

Self-Downloading Binaries

  • Boot is now comprised of three pieces: the loader, application, and
    library.
    • The library is a set of Clojure dependencies in which all of the
      Boot namespaces are distributed.
    • The application is a Java uberjar that handles bootstrapping the
      infrastructure for creating pods and running Clojure programs.
    • The loader is new--it's a Java program with no dependencies that
      handles downloading the application as needed. It is what the user
      will call from the command line.
  • From this release onwards:
    • We will publish an app binary for each new boot lib version.
    • An exception is thrown if app and library versions don't match.
    • App name will be "boot.jar", cross-platform.
    • Loader will be "boot.sh" and "boot.exe", built in the same way as
      the previous versions of the app were (i.e. executable jar shell
      script for Unix, Launch4J executable for Windows).
  • Previous releases are also supported by the new loader--the loader
    will ensure that a compatible version of the app will be used with
    the specified legacy version of the boot lib.

Fixes #229
Fixes #300

Properties Files
================

- Boot now supports specifying any env var (eg. BOOT_VERSION) from
  properties files.

- Setting BOOT_VERSION and BOOT_CLOJURE_VERSION is no longer required.

- System properties are now supported in addition to properties files
  and environment variables.

- Settings will be merged in the following order:

  1. BOOT_HOME/cache/boot.properties (deprecated)
  2. BOOT_HOME/boot.properties
  3. <git project dir>/boot.properties
  4. CWD/boot.properties
  5. environment variables
  6. system properties

  For example:

  CWD/boot.properties settings override BOOT_HOME/boot.properties,
  environment variables override all properties files, and system
  properties override everything else.

Self-Downloading Binaries
=========================

- Boot is now comprised of three pieces: the loader, application, and
  library.

  - The library is a set of Clojure dependencies in which all of the
    Boot namespaces are distributed.
  - The application is a Java uberjar that handles bootstrapping the
    infrastructure for creating pods and running Clojure programs.
  - The loader is new--it's a Java program with no dependencies that
    handles downloading the application as needed. It is what the user
    will call from the command line.

- From this release onwards:

  - We will publish an app binary for each new boot lib version.
  - An exception is thrown if app and library versions don't match.
  - App name will be "boot.jar", cross-platform.
  - Loader will be "boot.sh" and "boot.exe", built in the same way as
    the previous versions of the app were (i.e. executable jar shell
    script for Unix, Launch4J executable for Windows).

- Previous releases are also supported by the new loader--the loader
  will ensure that a compatible version of the app will be used with
  the specified legacy version of the boot lib.

The Loader
==========

- A self-contained Java program with no dependencies, packaged in
  executable JAR format:

  - Unix: JAR with bash shell script prelude (boot.sh)
  - Windows: Launch4J produced executable (boot.exe)

- Caches app uberjar in BOOT_HOME/cache/bin/BOOT_VERSION/boot.jar.

- In pseudo code this is what it does:

      (def app-jar-file
        (if BOOT_VERSION
          (or (cached BOOT_VERSION) (download-and-cache BOOT_VERSION))
          (or (latest-cached) (download-and-cache "2.3.0"))))

      (defn -main [& argv]
        (doto (new-classloader app-jar-file)
              (apply-method "boot.App" "main" argv)))

- There is a mapping from lib version -> app version for previous
  releases in the "boot/tag-release.properties" resource. This is used
  to download the correct version of the app for previous versions of
  the boot lib (when there wasn't an app release for every lib version).
micha added a commit that referenced this pull request Oct 26, 2015
Self-downloading binaries, properties files
@micha micha merged commit 123d255 into master Oct 26, 2015
@micha micha removed the in progress label Oct 26, 2015
@micha micha deleted the download-exe branch October 26, 2015 22:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant