Hi Bertrand,
2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <bdelacre...@apache.org>: > > Can we call this "startup model" BTW? It's more descriptive than > slingstart. > > I'm fine with nearly any name, I just picked the first thing running through my brain... While "startup model" is more descriptive, the model can also be used to describe partial systems (being it a subsystem etc.), therefore "startup" is slightly missleading. The same goes with "instance model". I thought about "runtime model" but that seems to be not 100% correct, either :) > 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. > Yepp, exactly. Funnily, I found YAML to verbose after experimenting with it ) > > 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. > Yes, although this is not exactly part of the model. But I agree that tooling should work in this way. For example the maven plugin does it like this. > > 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? > > Sure, so: :boot - is the same as we have in the bundle list with the "boot" start level. So this is what you need to bootstrap the installation, it's similar to your classpath elements from crankstart. :base - is special for Sling launchpad based installation. it just defines the maven artifact for the Sling launchpad. Maybe rename this to :launchpad? :standalone - is the opposite of :webapp :) So if you're describing different deliverables in one model, you can specify deliverable-specific stuff. > 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? > :) Potentially yes, however we have to find out when a configuration ends - if we can simplify the format and require that a configuration ends with a blank line, I think we can do this. > > 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. > It's the pax url notion, just without "mvn:" upfront - to avoid that people try using http: or other schemes I think we converting the launchpad xml to the text format, I added "/jar" all over the place :) But it can simply be left out, the parser supports this. > 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. > I agree, I think digest and signature are the only things for now. > > 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]. > Yes, both supported. Configs are by default felix-format, with config:properties you can use property format. > > 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. > Yepp, I use the same notion as used for naming configuration files, factory pid is separated by a dash from the alias (unique id), so org.my.factory.pid-some.unique.ID marks the config as a factory configuration with that id. So basically reusing what we're already used to > > Lots of questions - but that's mostly details, we agree on the general > idea! > Yepp, I guess we'll have some rounds of those :) But the good thing is we now have a working model which we can use to experiment with. Carsten > > -Bertrand > > [1] > http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
