Hi Carsten, On Sat, Sep 27, 2014 at 5:48 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > ...You can find the sample definition at: > http://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/systems/ > ...
Thanks for this - as discussed last week at adaptTo I like the idea very much, it will allow us to abstract the actual launchers (launchpad, crankstart, karaf, webapp etc) from what's being launched, very cool. I have also updated https://cwiki.apache.org/confluence/display/SLING/Sling+NG+Launcher to reflect the latest ideas, IMO the startup model should meet that launcher's design goals. Can we call this "startup model" BTW? It's more descriptive than slingstart. I'm fine with a structured text format that's not YAML, as long as it's diff-friendly and allows for comments. The benefit is that we can customize the syntax for our actual needs. Comments on your sample model files, in no particular order: How do we handle conflicting definitions when reading multiple model files? Variables for example might be defined several times. I suggest reading the files in alphanumeric order of their filenames, and failing if a variable is defined twice. feature: :boot - what does :boot mean? Sounds a bit magic, like feature: :standalone and feature: :base. If you can explain the idea behind that we might find a more self-explaining notation? artifact: org.slf4j/slf4j-api/1.7.6/jar - can we get rid of the artifact: prefix for all those artifact lines and make it the default? Same for the /jar suffix, can we make that the default like pax URL does? In general I'd suggest using the pax URL notation, even if we implement only some of it for now. Do we need any other artifact metadata besides a digest or signature? If not, to keep things simple we might just specify those things in brackets like org.slf4j/slf4j-api/1.7.6/jar (sha1:123123fc45de34124345cf324324de) Having it on the same line makes it more diff-friendly. Configs: how about data types? Crankstart supports both plain configs where all properties are strings, and Felix-format configs like the config felix.format.test at [1]. How about factory configs? In crankstart [1] I had to use a reserved CRANKSTART_CONFIG_ID=some.unique.ID property, to avoid recreating a factory config if the same model is started twice. Otherwise there's no way to know if the corresponding factory config was already created, as its ID is assigned by the OSGi framework. Lots of questions - but that's mostly details, we agree on the general idea! -Bertrand [1] http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt
