Hi
2014-10-01 12:57 GMT+02:00 Dominik Süß <dominik.su...@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 <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
> >
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
