You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2014/10/01 12:44:21 UTC
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 <cz...@apache.org>:
> Hi Robert,
>
>
> 2014-09-30 17:22 GMT+02:00 Robert Munteanu <ro...@apache.org>:
>
>> 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 <cz...@apache.org>:
>> >
>> >> Hi,
>> >>
>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cz...@apache.org>:
>> >>
>> >>> Hi Bertrand,
>> >>>
>> >>>
>> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <
>> bdelacretaz@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
>> >> cziegeler@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > Adobe Research Switzerland
>> > cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Updates to the Slingstart Model
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
2014-10-01 14:06 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:
> Hi,
>
> On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler <cz...@apache.org>
> 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:<blank>)
>
> 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
cziegeler@apache.org
Re: Updates to the Slingstart Model
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler <cz...@apache.org> 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:<blank>)
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
Posted by Carsten Ziegeler <cz...@apache.org>.
2014-10-01 12:55 GMT+02:00 Robert Munteanu <ro...@lmn.ro>:
> 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 <cz...@apache.org>
> 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 <cz...@apache.org>:
> >
> >> Hi Robert,
> >>
> >>
> >> 2014-09-30 17:22 GMT+02:00 Robert Munteanu <ro...@apache.org>:
> >>
> >>> 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 <cz...@apache.org>:
> >>> >
> >>> >> Hi,
> >>> >>
> >>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cz...@apache.org>:
> >>> >>
> >>> >>> Hi Bertrand,
> >>> >>>
> >>> >>>
> >>> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <
> >>> bdelacretaz@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
> >>> >> cziegeler@apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Carsten Ziegeler
> >>> > Adobe Research Switzerland
> >>> > cziegeler@apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org
>
>
>
> --
> Sent from my (old) computer
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Updates to the Slingstart Model
Posted by Robert Munteanu <ro...@lmn.ro>.
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 <cz...@apache.org> 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 <cz...@apache.org>:
>
>> Hi Robert,
>>
>>
>> 2014-09-30 17:22 GMT+02:00 Robert Munteanu <ro...@apache.org>:
>>
>>> 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 <cz...@apache.org>:
>>> >
>>> >> Hi,
>>> >>
>>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cz...@apache.org>:
>>> >>
>>> >>> Hi Bertrand,
>>> >>>
>>> >>>
>>> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <
>>> bdelacretaz@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
>>> >> cziegeler@apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Carsten Ziegeler
>>> > Adobe Research Switzerland
>>> > cziegeler@apache.org
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Sent from my (old) computer
Re: Updates to the Slingstart Model
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi
2014-10-01 12:57 GMT+02:00 Dominik Süß <do...@gmail.com>:
> 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 <cz...@apache.org>
> 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 <cz...@apache.org>:
> >
> > > Hi Robert,
> > >
> > >
> > > 2014-09-30 17:22 GMT+02:00 Robert Munteanu <ro...@apache.org>:
> > >
> > >> 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 <cz...@apache.org>:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cziegeler@apache.org
> >:
> > >> >>
> > >> >>> Hi Bertrand,
> > >> >>>
> > >> >>>
> > >> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <
> > >> bdelacretaz@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
> > >> >> cziegeler@apache.org
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Carsten Ziegeler
> > >> > Adobe Research Switzerland
> > >> > cziegeler@apache.org
> > >>
> > >
> > >
> > >
> > > --
> > > Carsten Ziegeler
> > > Adobe Research Switzerland
> > > cziegeler@apache.org
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org
> >
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Updates to the Slingstart Model
Posted by Dominik Süß <do...@gmail.com>.
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 <cz...@apache.org>
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 <cz...@apache.org>:
>
> > Hi Robert,
> >
> >
> > 2014-09-30 17:22 GMT+02:00 Robert Munteanu <ro...@apache.org>:
> >
> >> 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 <cz...@apache.org>:
> >> >
> >> >> Hi,
> >> >>
> >> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cz...@apache.org>:
> >> >>
> >> >>> Hi Bertrand,
> >> >>>
> >> >>>
> >> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <
> >> bdelacretaz@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
> >> >> cziegeler@apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Carsten Ziegeler
> >> > Adobe Research Switzerland
> >> > cziegeler@apache.org
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org
> >
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>