...
- 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.