2014-10-01 12:55 GMT+02:00 Robert Munteanu <[email protected]>: > 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 <[email protected]> > 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 <[email protected]>: > > > >> Hi Robert, > >> > >> > >> 2014-09-30 17:22 GMT+02:00 Robert Munteanu <[email protected]>: > >> > >>> 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 <[email protected]>: > >>> > > >>> >> Hi, > >>> >> > >>> >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <[email protected]>: > >>> >> > >>> >>> Hi Bertrand, > >>> >>> > >>> >>> > >>> >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz < > >>> [email protected]>: > >>> >>> > >>> >>>> > >>> >>>> 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 > >>> >> [email protected] > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > Carsten Ziegeler > >>> > Adobe Research Switzerland > >>> > [email protected] > >>> > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> [email protected] > >> > > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > [email protected] > > > > -- > Sent from my (old) computer > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
