Allow other env variables and subsets in boot.properties #229
Comments
micha
added a commit
that referenced
this issue
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. <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.
micha
added a commit
that referenced
this issue
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. <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 issue
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. <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 issue
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. <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 issue
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. <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 issue
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. <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).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: