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 <cziege...@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 <cziege...@apache.org>:
>
>> Hi Robert,
>>
>>
>> 2014-09-30 17:22 GMT+02:00 Robert Munteanu <romb...@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 <cziege...@apache.org>:
>>> >
>>> >> Hi,
>>> >>
>>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>:
>>> >>
>>> >>> 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
--
Sent from my (old) computer
