Re: Updates to the Slingstart Model
2014-10-01 15:19 GMT+02:00 Bertrand Delacretaz : > Hi, > > On Wed, Oct 1, 2014 at 3:13 PM, Carsten Ziegeler > wrote: > > 2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz : > >> ...Should have both local (to the feature) and global variables?... > > > Variables are currently local to a feature - do we need global variables? > > When e.g. overriding a variable from a system property it could use > > "feature.VARNAME" as the key... > > That should work, I agree, but in your example is "feature" the ID of > a feature? If yes where is it defined? > > It's the feature name from the first line: [feature name=REQUIRED] >> What is "sling.options", does it already have a defined meaning?... > > This is a defined framework property for the sling run mode handling. It > > tells Sling's launchpad that one of the two run modes will be active, but > > exactly one... > > Ah, ok - the name does not say anything about that, should rather be > "sling.runmode.options"? We might accept both names for now and > deprecate the old "sling.options" name? > > Sure we could do that - I agree that sling.runmode.options is a little bit nicer. I don't have a strange urge to do the deprecation though :) > > ...I think having the attributes of a section (run mode, start level) in > the > > same line is more readable and understandable > > Ok, that works for me as long as run mode and start level as treated > in the same way, as they are orthogonal. > Yes, I agree. Cool, it seems we have a first agreement. I'll update the implementation with the points discussed. Thanks Carsten > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Updates to the Slingstart Model
Hi, On Wed, Oct 1, 2014 at 3:13 PM, Carsten Ziegeler wrote: > 2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz : >> ...Should have both local (to the feature) and global variables?... > Variables are currently local to a feature - do we need global variables? > When e.g. overriding a variable from a system property it could use > "feature.VARNAME" as the key... That should work, I agree, but in your example is "feature" the ID of a feature? If yes where is it defined? >> What is "sling.options", does it already have a defined meaning?... > This is a defined framework property for the sling run mode handling. It > tells Sling's launchpad that one of the two run modes will be active, but > exactly one... Ah, ok - the name does not say anything about that, should rather be "sling.runmode.options"? We might accept both names for now and deprecate the old "sling.options" name? > ...I think having the attributes of a section (run mode, start level) in the > same line is more readable and understandable Ok, that works for me as long as run mode and start level as treated in the same way, as they are orthogonal. -Bertrand
Re: Updates to the Slingstart Model
Hi, 2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz : > I would require a header like > > [sling.feature] > name=Example feature > description=Optional description > > to make sure people at least think about what they put in there ;-) > > Good point, agreed (I don't agree on the syntax though :) ) > > Should have both local (to the feature) and global variables? We can > simply require global variables to have a name starting with g. like > g.oak.version - a variable that does not start with g. is then local > to the feature file. And complain if a global variable is set more > than once. > Variables are currently local to a feature - do we need global variables? When e.g. overriding a variable from a system property it could use "feature.VARNAME" as the key. > > Are [settings] meant to be OSGi framework settings? I need those for > Crankstart. > > Yes. > What is "sling.options", does it already have a defined meaning? > This is a defined framework property for the sling run mode handling. It tells Sling's launchpad that one of the two run modes will be active, but exactly one. If not specified by the environment, the first one is activated automatically. > > As mentioned in my previous message I suggest > > [artifacts] > runModes:jackrabbit,author > startLevel:5 > commons-io/commons-io/1.4/jar > ... > > Instead of embedding run modes and start level in section headers. I'm > using colons after the property names as we used to have > artifact:commons... which is now the default, but we might have > installer:some.artifact or other similar property qualifiers. > > I think having the attributes of a section (run mode, start level) in the same line is more readable and understandable. We also have the metadata notation, so your use case of adding the "installer" info could be handled today by this. Carsten > Apart from that I think your example covers our immediate needs, and > the syntax is sufficiently extensible - it seems to have everything I > currently use in Crankstart > ( > http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt > ) > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Updates to the Slingstart Model
Hi, On Tue, Sep 30, 2014 at 9:21 AM, Carsten Ziegeler wrote: > I've thought a little bit more about the model and I came up with a > slightly different syntax... > https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt ... Looks good to me, a few comments below. I would require a header like [sling.feature] name=Example feature description=Optional description to make sure people at least think about what they put in there ;-) And require it before any comments so that such files can be identified by the unix "file" command. Should have both local (to the feature) and global variables? We can simply require global variables to have a name starting with g. like g.oak.version - a variable that does not start with g. is then local to the feature file. And complain if a global variable is set more than once. Are [settings] meant to be OSGi framework settings? I need those for Crankstart. What is "sling.options", does it already have a defined meaning? As mentioned in my previous message I suggest [artifacts] runModes:jackrabbit,author startLevel:5 commons-io/commons-io/1.4/jar ... Instead of embedding run modes and start level in section headers. I'm using colons after the property names as we used to have artifact:commons... which is now the default, but we might have installer:some.artifact or other similar property qualifiers. Apart from that I think your example covers our immediate needs, and the syntax is sufficiently extensible - it seems to have everything I currently use in Crankstart (http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt) -Bertrand
Re: Updates to the Slingstart Model
Hi,
2014-10-01 14:06 GMT+02:00 Bertrand Delacretaz :
> Hi,
>
> On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler
> wrote:
> ...
> > [artifacts startLevel=1 runMode=jackrabbit]
> >..artifacts for level 1
> > [configurations runMode=jackrabbit]
> > ..configurations
>
> I'd write this a bit differently to make it obvious that start level
> and run mode apply only to the current section:
>
> [artifacts]
>startLevel:1
>runModes:jackrabbit,author
>...
>
> [configurations]
> startLevel:2
> (will use runModes:)
>
> And require, while parsing, those statements to be at the beginning of
> the section, before any artifacts.
>
> It's a bit more typing but things are then obvious, and one can always
> use ${variables} for lists of run modes for example.
>
>
But it complicates the parser, as it would need special casing to check for
the startLevel: and runModes: key words and personally I think having all
the info on one line is a little bit nicer. Its already obvious that
startLevel and runMode only apply to the current section as they are part
of the section definition.
[artifacts runMode=jackrabbit]
[configurations]
in contrast to
[artifacts]
runModes:jackrabbit
[configurations]
If you think about having a lot listed under artifacts, it's easy to miss
that the first line is actually not an artifact but an attribute of the
section.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: Updates to the Slingstart Model
Hi,
On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler wrote:
...
> [artifacts startLevel=1 runMode=jackrabbit]
>..artifacts for level 1
> [configurations runMode=jackrabbit]
> ..configurations
I'd write this a bit differently to make it obvious that start level
and run mode apply only to the current section:
[artifacts]
startLevel:1
runModes:jackrabbit,author
...
[configurations]
startLevel:2
(will use runModes:)
And require, while parsing, those statements to be at the beginning of
the section, before any artifacts.
It's a bit more typing but things are then obvious, and one can always
use ${variables} for lists of run modes for example.
-Bertrand
Re: Updates to the Slingstart Model
On Tue, Sep 30, 2014 at 8:11 AM, Carsten Ziegeler wrote: > What about Sling Provisioning Model (SPM) ?.. I like that name, +1 -Bertrand
Re: Updates to the Slingstart Model
Hi
2014-10-01 12:57 GMT+02:00 Dominik Süß :
> Hi Carsten,
>
> I probably just struggle with the naming but I guess runModes should
> provide similar capabilities as runmodes currently do (with the
> config.runmode options and so on).
>
Yep, exactly
> Therefore I wonder if it really reasonable to splitt runmodes or to better
> have the second one and potentially assign configurations, settings and
> artifacts to multiple runmodes. As soon as one of the runmodes is active
> this would be activated (basically runmodes would be used as toggles for
> the fragments).
>
> Or did I get this completely wrong?
>
This is how it is - you assign artifacts (including configs and settings)
to run mode(s).
So, if artifacts are assigned to run mode A, and A is active, these
artifacts are installed.
If you assign them to run modes A,B then if both A and B are active these
artifacts are installed.
So it's like the config/install directorie and also exactly like todays
launchpad
Carsten
> Cheers
> Dominik
>
> On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler
> wrote:
>
> > So what do people think?
> >
> > Should we rather go with
> >
> > [runMode name=jackrabbit]
> > [artifacts startLevel=1]
> >..artifacts for level 1
> > [artifacts startLevel=5]
> > ..artifacts for level 5
> > [configurations]
> > ..configurations
> > [settings]
> > .settings
> >
> > or
> >
> > [artifacts startLevel=1 runMode=jackrabbit]
> >..artifacts for level 1
> > [artifacts startLevel=5 runMode=jackrabbit]
> > ..artifacts for level 5
> > [configurations runMode=jackrabbit]
> > ..configurations
> > [settings runMode=jackrabbit]
> > .settings
> >
> > The latter is easier to read/understand but requires more typing.
> >
> > WDYT?
> >
> > Please note that this only affects the textual representation, the object
> > model is still tree based.
> >
> > Carsten
> >
> > 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler :
> >
> > > Hi Robert,
> > >
> > >
> > > 2014-09-30 17:22 GMT+02:00 Robert Munteanu :
> > >
> > >> I haven't looked very much in depth at this, but I like where this is
> > >> heading. A couple of questions/nitpicks:
> > >>
> > >> 1. Attaching additional information to artifacts currently looks like
> > this
> > >>
> > >> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
> > >>
> > >> How will multiple attributes look like? We can have a CSV list, e.g.
> > >> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
> > >> {att1=val1} {att2=val2} . I think the first one looks better but needs
> > >> to define escaping.
> > >>
> > >
> > > Also, when I see a '{' '}' block I immediately think of code. Perhaps
> > >> it would be more intuitive to have these attributes enclosed in
> > >> parenthesis, e.g. '(sha1=CAFEBABE)'.
> > >>
> > >> While writing the parser I noticed that { } is not the best option
> > > anyway, as we also use this for variables ${var}
> > > So I changed to '[', ']' and multiple attributes would be
> > > [att1=val1,att2=val2]. Whitespaces within the block are ignored.
> > > Right now, no escaping is supported and simply assumed that neither the
> > > attribute name nor the value contain a "=" :)
> > > But that would be easy to fix.
> > >
> > > 2. One of the example OSGi configs has a string value quoted and also
> > >> escaped
> > >>
> > >> # A plain configuration
> > >> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
> > >> name="Default\ NodeStore"
> > >> repository.home="sling/oak/repository"
> > >>
> > >> Would it not be simpler to have the value be "Default NodeStore" ?
> > >>
> > >> This is how the Apache Felix CA Implementation writes the stuff out. I
> > > think that's a bug in the implementation and a space should not be
> > escaped.
> > > However, you can write:
> > > name="Default NodeStore" and this is correctly read. But once config
> > admin
> > > writes the configuration out, the space is escaped.
> > >
> > >
> > >> 3. Runmode configuration needs an additional section, and is ( I think
> > >> ) the only case where we have nested sections. Would it simplify the
> > >> model and make the file easier to understand by including them as
> > >> attributes to various sections ? I think this model looks somewhat
> > >> flat - which is a good thing - but is not very good at expressing deep
> > >> nesting like XML/JSON.
> > >>
> > >> [artifacts startLevel=15 runModeName=jackrabbit]
> > >> org.apache.derby/derby/10.5.3.0_1/jar
> > >>
> > >>
> >
> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
> > >>
> > >>
> > >> Yes, this is the area where I'm not 100% sure either. We have a nested
> > > model: feature -> run modes -> artifact groups (aka start level).
> > > If you're not using run modes nor start levels, then it's nicely flat
> and
> > > looks good. As soon as you're using one of it or even in combination it
> > > gets worse (this is where all tree based approaches shine).
> > > We could do what you're suggesting, but that requ
Re: Updates to the Slingstart Model
2014-10-01 12:55 GMT+02:00 Robert Munteanu :
> Well, I don't have a strong preference either way - just playing the
> devil's advocate a bit.
Which is great, it's better to sort these things out now before we're using
it all over the place.
> I think there's a third option as well, making
> the runMode a property of the config file, so all
> configurations/artifacts in a config file would be automatically
> assigned to the defined runMode - if any.
>
No, that doesn't work - a feature can have a set of artifacts without a run
mode but maybe also specific artifacts depending on the run mode. Think of
some feature building on top of JCR where we have a special implementation
for JR2 or Oak.
Carsten
>
> Robert
>
> On Wed, Oct 1, 2014 at 1:44 PM, Carsten Ziegeler
> wrote:
> > So what do people think?
> >
> > Should we rather go with
> >
> > [runMode name=jackrabbit]
> > [artifacts startLevel=1]
> >..artifacts for level 1
> > [artifacts startLevel=5]
> > ..artifacts for level 5
> > [configurations]
> > ..configurations
> > [settings]
> > .settings
> >
> > or
> >
> > [artifacts startLevel=1 runMode=jackrabbit]
> >..artifacts for level 1
> > [artifacts startLevel=5 runMode=jackrabbit]
> > ..artifacts for level 5
> > [configurations runMode=jackrabbit]
> > ..configurations
> > [settings runMode=jackrabbit]
> > .settings
> >
> > The latter is easier to read/understand but requires more typing.
> >
> > WDYT?
> >
> > Please note that this only affects the textual representation, the object
> > model is still tree based.
> >
> > Carsten
> >
> > 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler :
> >
> >> Hi Robert,
> >>
> >>
> >> 2014-09-30 17:22 GMT+02:00 Robert Munteanu :
> >>
> >>> I haven't looked very much in depth at this, but I like where this is
> >>> heading. A couple of questions/nitpicks:
> >>>
> >>> 1. Attaching additional information to artifacts currently looks like
> this
> >>>
> >>> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
> >>>
> >>> How will multiple attributes look like? We can have a CSV list, e.g.
> >>> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
> >>> {att1=val1} {att2=val2} . I think the first one looks better but needs
> >>> to define escaping.
> >>>
> >>
> >> Also, when I see a '{' '}' block I immediately think of code. Perhaps
> >>> it would be more intuitive to have these attributes enclosed in
> >>> parenthesis, e.g. '(sha1=CAFEBABE)'.
> >>>
> >>> While writing the parser I noticed that { } is not the best option
> >> anyway, as we also use this for variables ${var}
> >> So I changed to '[', ']' and multiple attributes would be
> >> [att1=val1,att2=val2]. Whitespaces within the block are ignored.
> >> Right now, no escaping is supported and simply assumed that neither the
> >> attribute name nor the value contain a "=" :)
> >> But that would be easy to fix.
> >>
> >> 2. One of the example OSGi configs has a string value quoted and also
> >>> escaped
> >>>
> >>> # A plain configuration
> >>> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
> >>> name="Default\ NodeStore"
> >>> repository.home="sling/oak/repository"
> >>>
> >>> Would it not be simpler to have the value be "Default NodeStore" ?
> >>>
> >>> This is how the Apache Felix CA Implementation writes the stuff out. I
> >> think that's a bug in the implementation and a space should not be
> escaped.
> >> However, you can write:
> >> name="Default NodeStore" and this is correctly read. But once config
> admin
> >> writes the configuration out, the space is escaped.
> >>
> >>
> >>> 3. Runmode configuration needs an additional section, and is ( I think
> >>> ) the only case where we have nested sections. Would it simplify the
> >>> model and make the file easier to understand by including them as
> >>> attributes to various sections ? I think this model looks somewhat
> >>> flat - which is a good thing - but is not very good at expressing deep
> >>> nesting like XML/JSON.
> >>>
> >>> [artifacts startLevel=15 runModeName=jackrabbit]
> >>> org.apache.derby/derby/10.5.3.0_1/jar
> >>>
> >>>
> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
> >>>
> >>>
> >>> Yes, this is the area where I'm not 100% sure either. We have a nested
> >> model: feature -> run modes -> artifact groups (aka start level).
> >> If you're not using run modes nor start levels, then it's nicely flat
> and
> >> looks good. As soon as you're using one of it or even in combination it
> >> gets worse (this is where all tree based approaches shine).
> >> We could do what you're suggesting, but that requires repeating the same
> >> stuff over and over, e.g if you have two start levels for a runmode, you
> >> have to specify the run mode name twice etc.
> >>
> >> Carsten
> >>
> >>
> >>> Thanks,
> >>>
> >>> Robert
> >>>
> >>> >
> >>> > Regards
> >>> > Carsten
> >>> >
> >>> > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
> >>> >
> >>> >> Hi,
> >>> >>
> >>> >> 2014-0
Re: Updates to the Slingstart Model
Hi Carsten,
I probably just struggle with the naming but I guess runModes should
provide similar capabilities as runmodes currently do (with the
config.runmode options and so on).
Therefore I wonder if it really reasonable to splitt runmodes or to better
have the second one and potentially assign configurations, settings and
artifacts to multiple runmodes. As soon as one of the runmodes is active
this would be activated (basically runmodes would be used as toggles for
the fragments).
Or did I get this completely wrong?
Cheers
Dominik
On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler
wrote:
> So what do people think?
>
> Should we rather go with
>
> [runMode name=jackrabbit]
> [artifacts startLevel=1]
>..artifacts for level 1
> [artifacts startLevel=5]
> ..artifacts for level 5
> [configurations]
> ..configurations
> [settings]
> .settings
>
> or
>
> [artifacts startLevel=1 runMode=jackrabbit]
>..artifacts for level 1
> [artifacts startLevel=5 runMode=jackrabbit]
> ..artifacts for level 5
> [configurations runMode=jackrabbit]
> ..configurations
> [settings runMode=jackrabbit]
> .settings
>
> The latter is easier to read/understand but requires more typing.
>
> WDYT?
>
> Please note that this only affects the textual representation, the object
> model is still tree based.
>
> Carsten
>
> 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler :
>
> > Hi Robert,
> >
> >
> > 2014-09-30 17:22 GMT+02:00 Robert Munteanu :
> >
> >> I haven't looked very much in depth at this, but I like where this is
> >> heading. A couple of questions/nitpicks:
> >>
> >> 1. Attaching additional information to artifacts currently looks like
> this
> >>
> >> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
> >>
> >> How will multiple attributes look like? We can have a CSV list, e.g.
> >> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
> >> {att1=val1} {att2=val2} . I think the first one looks better but needs
> >> to define escaping.
> >>
> >
> > Also, when I see a '{' '}' block I immediately think of code. Perhaps
> >> it would be more intuitive to have these attributes enclosed in
> >> parenthesis, e.g. '(sha1=CAFEBABE)'.
> >>
> >> While writing the parser I noticed that { } is not the best option
> > anyway, as we also use this for variables ${var}
> > So I changed to '[', ']' and multiple attributes would be
> > [att1=val1,att2=val2]. Whitespaces within the block are ignored.
> > Right now, no escaping is supported and simply assumed that neither the
> > attribute name nor the value contain a "=" :)
> > But that would be easy to fix.
> >
> > 2. One of the example OSGi configs has a string value quoted and also
> >> escaped
> >>
> >> # A plain configuration
> >> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
> >> name="Default\ NodeStore"
> >> repository.home="sling/oak/repository"
> >>
> >> Would it not be simpler to have the value be "Default NodeStore" ?
> >>
> >> This is how the Apache Felix CA Implementation writes the stuff out. I
> > think that's a bug in the implementation and a space should not be
> escaped.
> > However, you can write:
> > name="Default NodeStore" and this is correctly read. But once config
> admin
> > writes the configuration out, the space is escaped.
> >
> >
> >> 3. Runmode configuration needs an additional section, and is ( I think
> >> ) the only case where we have nested sections. Would it simplify the
> >> model and make the file easier to understand by including them as
> >> attributes to various sections ? I think this model looks somewhat
> >> flat - which is a good thing - but is not very good at expressing deep
> >> nesting like XML/JSON.
> >>
> >> [artifacts startLevel=15 runModeName=jackrabbit]
> >> org.apache.derby/derby/10.5.3.0_1/jar
> >>
> >>
> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
> >>
> >>
> >> Yes, this is the area where I'm not 100% sure either. We have a nested
> > model: feature -> run modes -> artifact groups (aka start level).
> > If you're not using run modes nor start levels, then it's nicely flat and
> > looks good. As soon as you're using one of it or even in combination it
> > gets worse (this is where all tree based approaches shine).
> > We could do what you're suggesting, but that requires repeating the same
> > stuff over and over, e.g if you have two start levels for a runmode, you
> > have to specify the run mode name twice etc.
> >
> > Carsten
> >
> >
> >> Thanks,
> >>
> >> Robert
> >>
> >> >
> >> > Regards
> >> > Carsten
> >> >
> >> > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
> >> >
> >> >> Hi,
> >> >>
> >> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler :
> >> >>
> >> >>> 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,
Re: Updates to the Slingstart Model
Well, I don't have a strong preference either way - just playing the
devil's advocate a bit. I think there's a third option as well, making
the runMode a property of the config file, so all
configurations/artifacts in a config file would be automatically
assigned to the defined runMode - if any.
Robert
On Wed, Oct 1, 2014 at 1:44 PM, Carsten Ziegeler wrote:
> So what do people think?
>
> Should we rather go with
>
> [runMode name=jackrabbit]
> [artifacts startLevel=1]
>..artifacts for level 1
> [artifacts startLevel=5]
> ..artifacts for level 5
> [configurations]
> ..configurations
> [settings]
> .settings
>
> or
>
> [artifacts startLevel=1 runMode=jackrabbit]
>..artifacts for level 1
> [artifacts startLevel=5 runMode=jackrabbit]
> ..artifacts for level 5
> [configurations runMode=jackrabbit]
> ..configurations
> [settings runMode=jackrabbit]
> .settings
>
> The latter is easier to read/understand but requires more typing.
>
> WDYT?
>
> Please note that this only affects the textual representation, the object
> model is still tree based.
>
> Carsten
>
> 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler :
>
>> Hi Robert,
>>
>>
>> 2014-09-30 17:22 GMT+02:00 Robert Munteanu :
>>
>>> I haven't looked very much in depth at this, but I like where this is
>>> heading. A couple of questions/nitpicks:
>>>
>>> 1. Attaching additional information to artifacts currently looks like this
>>>
>>> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
>>>
>>> How will multiple attributes look like? We can have a CSV list, e.g.
>>> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
>>> {att1=val1} {att2=val2} . I think the first one looks better but needs
>>> to define escaping.
>>>
>>
>> Also, when I see a '{' '}' block I immediately think of code. Perhaps
>>> it would be more intuitive to have these attributes enclosed in
>>> parenthesis, e.g. '(sha1=CAFEBABE)'.
>>>
>>> While writing the parser I noticed that { } is not the best option
>> anyway, as we also use this for variables ${var}
>> So I changed to '[', ']' and multiple attributes would be
>> [att1=val1,att2=val2]. Whitespaces within the block are ignored.
>> Right now, no escaping is supported and simply assumed that neither the
>> attribute name nor the value contain a "=" :)
>> But that would be easy to fix.
>>
>> 2. One of the example OSGi configs has a string value quoted and also
>>> escaped
>>>
>>> # A plain configuration
>>> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
>>> name="Default\ NodeStore"
>>> repository.home="sling/oak/repository"
>>>
>>> Would it not be simpler to have the value be "Default NodeStore" ?
>>>
>>> This is how the Apache Felix CA Implementation writes the stuff out. I
>> think that's a bug in the implementation and a space should not be escaped.
>> However, you can write:
>> name="Default NodeStore" and this is correctly read. But once config admin
>> writes the configuration out, the space is escaped.
>>
>>
>>> 3. Runmode configuration needs an additional section, and is ( I think
>>> ) the only case where we have nested sections. Would it simplify the
>>> model and make the file easier to understand by including them as
>>> attributes to various sections ? I think this model looks somewhat
>>> flat - which is a good thing - but is not very good at expressing deep
>>> nesting like XML/JSON.
>>>
>>> [artifacts startLevel=15 runModeName=jackrabbit]
>>> org.apache.derby/derby/10.5.3.0_1/jar
>>>
>>> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
>>>
>>>
>>> Yes, this is the area where I'm not 100% sure either. We have a nested
>> model: feature -> run modes -> artifact groups (aka start level).
>> If you're not using run modes nor start levels, then it's nicely flat and
>> looks good. As soon as you're using one of it or even in combination it
>> gets worse (this is where all tree based approaches shine).
>> We could do what you're suggesting, but that requires repeating the same
>> stuff over and over, e.g if you have two start levels for a runmode, you
>> have to specify the run mode name twice etc.
>>
>> Carsten
>>
>>
>>> Thanks,
>>>
>>> Robert
>>>
>>> >
>>> > Regards
>>> > Carsten
>>> >
>>> > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
>>> >
>>> >> Hi,
>>> >>
>>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler :
>>> >>
>>> >>> 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 mode
Re: Updates to the Slingstart Model
So what do people think?
Should we rather go with
[runMode name=jackrabbit]
[artifacts startLevel=1]
..artifacts for level 1
[artifacts startLevel=5]
..artifacts for level 5
[configurations]
..configurations
[settings]
.settings
or
[artifacts startLevel=1 runMode=jackrabbit]
..artifacts for level 1
[artifacts startLevel=5 runMode=jackrabbit]
..artifacts for level 5
[configurations runMode=jackrabbit]
..configurations
[settings runMode=jackrabbit]
.settings
The latter is easier to read/understand but requires more typing.
WDYT?
Please note that this only affects the textual representation, the object
model is still tree based.
Carsten
2014-09-30 17:48 GMT+02:00 Carsten Ziegeler :
> Hi Robert,
>
>
> 2014-09-30 17:22 GMT+02:00 Robert Munteanu :
>
>> I haven't looked very much in depth at this, but I like where this is
>> heading. A couple of questions/nitpicks:
>>
>> 1. Attaching additional information to artifacts currently looks like this
>>
>> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
>>
>> How will multiple attributes look like? We can have a CSV list, e.g.
>> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
>> {att1=val1} {att2=val2} . I think the first one looks better but needs
>> to define escaping.
>>
>
> Also, when I see a '{' '}' block I immediately think of code. Perhaps
>> it would be more intuitive to have these attributes enclosed in
>> parenthesis, e.g. '(sha1=CAFEBABE)'.
>>
>> While writing the parser I noticed that { } is not the best option
> anyway, as we also use this for variables ${var}
> So I changed to '[', ']' and multiple attributes would be
> [att1=val1,att2=val2]. Whitespaces within the block are ignored.
> Right now, no escaping is supported and simply assumed that neither the
> attribute name nor the value contain a "=" :)
> But that would be easy to fix.
>
> 2. One of the example OSGi configs has a string value quoted and also
>> escaped
>>
>> # A plain configuration
>> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
>> name="Default\ NodeStore"
>> repository.home="sling/oak/repository"
>>
>> Would it not be simpler to have the value be "Default NodeStore" ?
>>
>> This is how the Apache Felix CA Implementation writes the stuff out. I
> think that's a bug in the implementation and a space should not be escaped.
> However, you can write:
> name="Default NodeStore" and this is correctly read. But once config admin
> writes the configuration out, the space is escaped.
>
>
>> 3. Runmode configuration needs an additional section, and is ( I think
>> ) the only case where we have nested sections. Would it simplify the
>> model and make the file easier to understand by including them as
>> attributes to various sections ? I think this model looks somewhat
>> flat - which is a good thing - but is not very good at expressing deep
>> nesting like XML/JSON.
>>
>> [artifacts startLevel=15 runModeName=jackrabbit]
>> org.apache.derby/derby/10.5.3.0_1/jar
>>
>> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
>>
>>
>> Yes, this is the area where I'm not 100% sure either. We have a nested
> model: feature -> run modes -> artifact groups (aka start level).
> If you're not using run modes nor start levels, then it's nicely flat and
> looks good. As soon as you're using one of it or even in combination it
> gets worse (this is where all tree based approaches shine).
> We could do what you're suggesting, but that requires repeating the same
> stuff over and over, e.g if you have two start levels for a runmode, you
> have to specify the run mode name twice etc.
>
> Carsten
>
>
>> Thanks,
>>
>> Robert
>>
>> >
>> > Regards
>> > Carsten
>> >
>> > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
>> >
>> >> Hi,
>> >>
>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler :
>> >>
>> >>> 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 :)
>> >>>
>> >>
>> >> What about Sling Provisioning Model (SPM) ?
>> >>
>> >> Carsten
>> >>
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> Adobe Research Switzerland
>> >> cziege...@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: Updates to the Slingstart Model
Hi Robert,
2014-09-30 17:22 GMT+02:00 Robert Munteanu :
> I haven't looked very much in depth at this, but I like where this is
> heading. A couple of questions/nitpicks:
>
> 1. Attaching additional information to artifacts currently looks like this
>
> org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
>
> How will multiple attributes look like? We can have a CSV list, e.g.
> {att1=val1,att2=val2} or multiple space-separated groups, e.g.
> {att1=val1} {att2=val2} . I think the first one looks better but needs
> to define escaping.
>
Also, when I see a '{' '}' block I immediately think of code. Perhaps
> it would be more intuitive to have these attributes enclosed in
> parenthesis, e.g. '(sha1=CAFEBABE)'.
>
> While writing the parser I noticed that { } is not the best option anyway,
as we also use this for variables ${var}
So I changed to '[', ']' and multiple attributes would be
[att1=val1,att2=val2]. Whitespaces within the block are ignored.
Right now, no escaping is supported and simply assumed that neither the
attribute name nor the value contain a "=" :)
But that would be easy to fix.
2. One of the example OSGi configs has a string value quoted and also
> escaped
>
> # A plain configuration
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
> name="Default\ NodeStore"
> repository.home="sling/oak/repository"
>
> Would it not be simpler to have the value be "Default NodeStore" ?
>
> This is how the Apache Felix CA Implementation writes the stuff out. I
think that's a bug in the implementation and a space should not be escaped.
However, you can write:
name="Default NodeStore" and this is correctly read. But once config admin
writes the configuration out, the space is escaped.
> 3. Runmode configuration needs an additional section, and is ( I think
> ) the only case where we have nested sections. Would it simplify the
> model and make the file easier to understand by including them as
> attributes to various sections ? I think this model looks somewhat
> flat - which is a good thing - but is not very good at expressing deep
> nesting like XML/JSON.
>
> [artifacts startLevel=15 runModeName=jackrabbit]
> org.apache.derby/derby/10.5.3.0_1/jar
>
> org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
>
>
> Yes, this is the area where I'm not 100% sure either. We have a nested
model: feature -> run modes -> artifact groups (aka start level).
If you're not using run modes nor start levels, then it's nicely flat and
looks good. As soon as you're using one of it or even in combination it
gets worse (this is where all tree based approaches shine).
We could do what you're suggesting, but that requires repeating the same
stuff over and over, e.g if you have two start levels for a runmode, you
have to specify the run mode name twice etc.
Carsten
> Thanks,
>
> Robert
>
> >
> > Regards
> > Carsten
> >
> > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
> >
> >> Hi,
> >>
> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler :
> >>
> >>> Hi Bertrand,
> >>>
> >>>
> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz >:
> >>>
>
> 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 :)
> >>>
> >>
> >> What about Sling Provisioning Model (SPM) ?
> >>
> >> Carsten
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: Updates to the Slingstart Model
Hi,
On Tue, Sep 30, 2014 at 10:21 AM, Carsten Ziegeler wrote:
> I've thought a little bit more about the model and I came up with a
> slightly different syntax. A file with examples can be found here:
> https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt
>
> The previous version messed up features and run modes and made them the
> same. But that's not true, a feature can have artifacts in different run
> modes.
> So I changed the model and now each file represents a single feature, a
> feature has a name which is usually derived from the file name of the model
> file.
>
> A feature has variables that can be used for the values of settings and
> configurations and also to specify artifacts.
>
> A feature consists of run modes - the global one is the default run mode
> and always active.
>
> A run mode can have settings, configurations, and artifacts.
>
> In the txt file, each part is introduced with a section notation, like
> [configurations], [artifacts] etc.
>
> An artifact is just a single line with the maven coordinates of the
> artifact. it can have additional information like the sha1 etc.
>
> A configuration is started with a line containing the pid or factory pid +
> alias, followed by the contents of the configuration and ends with an empty
> line.
>
> Each object in the model can have comments preceding the object.
>
> Based on this we'll have two utility methods: one for agregating a model
> based on features. This is e.g. reading a directory of model files in
> alphabetical order. The aggregation checks for unique variables etc.
> The second utility method is merging - it merges a complete (aggregated
> model) with another aggregated one. This allows for overlaying or customing.
>
> WDYT?
I haven't looked very much in depth at this, but I like where this is
heading. A couple of questions/nitpicks:
1. Attaching additional information to artifacts currently looks like this
org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE}
How will multiple attributes look like? We can have a CSV list, e.g.
{att1=val1,att2=val2} or multiple space-separated groups, e.g.
{att1=val1} {att2=val2} . I think the first one looks better but needs
to define escaping.
Also, when I see a '{' '}' block I immediately think of code. Perhaps
it would be more intuitive to have these attributes enclosed in
parenthesis, e.g. '(sha1=CAFEBABE)'.
2. One of the example OSGi configs has a string value quoted and also escaped
# A plain configuration
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService
name="Default\ NodeStore"
repository.home="sling/oak/repository"
Would it not be simpler to have the value be "Default NodeStore" ?
3. Runmode configuration needs an additional section, and is ( I think
) the only case where we have nested sections. Would it simplify the
model and make the file easier to understand by including them as
attributes to various sections ? I think this model looks somewhat
flat - which is a good thing - but is not very good at expressing deep
nesting like XML/JSON.
[artifacts startLevel=15 runModeName=jackrabbit]
org.apache.derby/derby/10.5.3.0_1/jar
org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar
Thanks,
Robert
>
> Regards
> Carsten
>
> 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler :
>
>> Hi,
>>
>> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler :
>>
>>> Hi Bertrand,
>>>
>>>
>>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz :
>>>
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 :)
>>>
>>
>> What about Sling Provisioning Model (SPM) ?
>>
>> Carsten
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
Re: Updates to the Slingstart Model
I've thought a little bit more about the model and I came up with a slightly different syntax. A file with examples can be found here: https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt The previous version messed up features and run modes and made them the same. But that's not true, a feature can have artifacts in different run modes. So I changed the model and now each file represents a single feature, a feature has a name which is usually derived from the file name of the model file. A feature has variables that can be used for the values of settings and configurations and also to specify artifacts. A feature consists of run modes - the global one is the default run mode and always active. A run mode can have settings, configurations, and artifacts. In the txt file, each part is introduced with a section notation, like [configurations], [artifacts] etc. An artifact is just a single line with the maven coordinates of the artifact. it can have additional information like the sha1 etc. A configuration is started with a line containing the pid or factory pid + alias, followed by the contents of the configuration and ends with an empty line. Each object in the model can have comments preceding the object. Based on this we'll have two utility methods: one for agregating a model based on features. This is e.g. reading a directory of model files in alphabetical order. The aggregation checks for unique variables etc. The second utility method is merging - it merges a complete (aggregated model) with another aggregated one. This allows for overlaying or customing. WDYT? Regards Carsten 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler : > Hi, > > 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler : > >> Hi Bertrand, >> >> >> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz : >> >>> >>> 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 :) >> > > What about Sling Provisioning Model (SPM) ? > > Carsten > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Updates to the Slingstart Model
Hi, 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler : > Hi Bertrand, > > > 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz : > >> >> 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 :) > What about Sling Provisioning Model (SPM) ? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Updates to the Slingstart Model
2014-09-29 23:12 GMT+02:00 Alexander Klimetschek :
> On 29.09.2014, at 06:36, Carsten Ziegeler wrote:
>
> >> 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
>
> We definitely should use JSONx that combines the awesomeness of JSON with
> the great structure of XML:
>
> https://twitter.com/DanHarper7/status/514822464673951744
>
> :)
>
>
{checking the calendar for the current datehmm it's not April}
Yeah, maybe we can find something even more verbose? :)
Carsten
> Cheers,
> Alex
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Re: Updates to the Slingstart Model
On 29.09.2014, at 06:36, Carsten Ziegeler wrote: >> 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 We definitely should use JSONx that combines the awesomeness of JSON with the great structure of XML: https://twitter.com/DanHarper7/status/514822464673951744 :) Cheers, Alex
Re: Updates to the Slingstart Model
Hi Bertrand, 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz : > > 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
Re: Updates to the Slingstart Model
Hi Carsten, On Sat, Sep 27, 2014 at 5:48 PM, Carsten Ziegeler 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
