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.

Sign up for GitHub

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

Jump to bottom

Add support for binary updating itself #300

Closed
Deraen opened this issue Oct 3, 2015 · 1 comment
Closed

Add support for binary updating itself #300

Deraen opened this issue Oct 3, 2015 · 1 comment
Assignees
@micha
Labels
Enhancement

Comments

@Deraen
Copy link
Member

Deraen commented Oct 3, 2015

boot -u could update the binary in addition to JARs.

Leiningen script should give quite good example how this could be done in Linux and OS X: https://github.com/technomancy/leiningen/blob/master/bin/lein
@Deraen
Copy link
Member Author

Deraen commented Oct 14, 2015

Here is an example of how to find latest Boot release from Github REST API and download it: https://github.com/Deraen/dotfiles/blob/master/bin/update-boot.sh

  • Needs some changes to remove dependency on jq
  • If-modified-since and checking 304 is not necessary, should just update binary when ever update is run.
  • Should use wget is curl is not available?
  • Needs to find path for current file

micha added a commit that referenced this issue Oct 26, 2015
@micha
Self-downloading binaries, properties files
dc7a52e 
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 micha mentioned this issue Oct 26, 2015
Merged
@micha micha self-assigned this Oct 26, 2015
micha added a commit that referenced this issue Oct 26, 2015
@micha
Self-downloading binaries, properties files
f87a55d 
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
@micha
Self-downloading binaries, properties files
c0f92fe 
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
@micha
Self-downloading binaries, properties files
87163df 
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
@micha
Self-downloading binaries, properties files
0f41df8 
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
@micha
Self-downloading binaries, properties files
464e735 
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 micha removed the in progress label Oct 26, 2015
This was referenced Oct 26, 2015
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@micha micha

Labels
Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@micha @Deraen