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 <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
>
