Page History

...

• Use a minimal launcher that "never" needs to change, like Crankstart does.
• Maybe combine declarative instructions (lists of bundles for example) with procedural statements ("start framework") for example to allow for optimized and deterministic startup scenarios.
• Allow for dynamic extensions of the startup mechanism, like Crankstart does.
• If using a runnable jar, allow for influencing the launcher setup (run modes probably) by renaming the runnable jar. That's a useful way of producing runnable jars with multiple modes that are very easy to repurpose, by just renaming.
• Maybe allow for pre-assembling the instance for faster startup, like downloading dependencies in advance and embedding in the launcher jar file or in a "sidecar" jar that can be accessed locally.
• The launcher can output a digest of the overall SIC, to be able to verify that multiple instances have the exact same model.
  

Open Questions

• Do we need or want run modes in the SIC? We might also create different deployments by combining a set of base SICs in different ways.
• Runtime or build time assembly? Crankstart gets and assembles artifacts at startup time, launchpad at build time.