subject:"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 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

Re: Updates to the Slingstart Model

2014-10-01 Thread Robert Munteanu

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

Re: Updates to the Slingstart Model

2014-10-01 Thread Dominik Süß

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

Re: Updates to the Slingstart Model

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

Re: Updates to the Slingstart Model

On Tue, Sep 30, 2014 at 8:11 AM, Carsten Ziegeler cziege...@apache.org wrote:
 What about Sling Provisioning Model (SPM) ?..

I like that name, +1
-Bertrand

Re: Updates to the Slingstart Model

Hi,

On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler cziege...@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

Hi,

2014-10-01 14:06 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:

 Hi,

 On Wed, Oct 1, 2014 at 12:44 PM, Carsten Ziegeler cziege...@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
cziege...@apache.org

Re: Updates to the Slingstart Model

Hi,

On Tue, Sep 30, 2014 at 9:21 AM, Carsten Ziegeler cziege...@apache.org wrote:
I've thought a little bit more about the model and I came up with a
slightly different syntax...
https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt
...

Looks good to me, a few comments below.

I would require a header like

[sling.feature]
name=Example feature
description=Optional description

to make sure people at least think about what they put in there ;-)

And require it before any comments so that such files can be
identified by the unix file command.

Should have both local (to the feature) and global variables? We can
simply require global variables to have a name starting with g. like
g.oak.version - a variable that does not start with g. is then local
to the feature file. And complain if a global variable is set more
than once.

Are [settings] meant to be OSGi framework settings? I need those for Crankstart.

What is sling.options, does it already have a defined meaning?

As mentioned in my previous message I suggest

[artifacts]
runModes:jackrabbit,author
startLevel:5
commons-io/commons-io/1.4/jar
...

Instead of embedding run modes and start level in section headers. I'm
using colons after the property names as we used to have
artifact:commons... which is now the default, but we might have
installer:some.artifact or other similar property qualifiers.

Apart from that I think your example covers our immediate needs, and
the syntax is sufficiently extensible - it seems to have everything I
currently use in Crankstart
(http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt)

-Bertrand

Re: Updates to the Slingstart Model

Hi,

2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:

I would require a header like

[sling.feature]
name=Example feature
description=Optional description

to make sure people at least think about what they put in there ;-)

Good point, agreed (I don't agree on the syntax though :) )

Variables are currently local to a feature - do we need global variables?
When e.g. overriding a variable from a system property it could use
feature.VARNAME as the key.

Are [settings] meant to be OSGi framework settings? I need those for
Crankstart.

Yes.

What is sling.options, does it already have a defined meaning?

This is a defined framework property for the sling run mode handling. It
tells Sling's launchpad that one of the two run modes will be active, but
exactly one. If not specified by the environment, the first one is
activated automatically.

As mentioned in my previous message I suggest

[artifacts]
runModes:jackrabbit,author
startLevel:5
commons-io/commons-io/1.4/jar
...

I think having the attributes of a section (run mode, start level) in the
same line is more readable and understandable.
We also have the metadata notation, so your use case of adding the
installer info could be handled today by this.

Carsten

Apart from that I think your example covers our immediate needs, and
the syntax is sufficiently extensible - it seems to have everything I
currently use in Crankstart
(
http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt
)

-Bertrand

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Updates to the Slingstart Model

Hi,

On Wed, Oct 1, 2014 at 3:13 PM, Carsten Ziegeler cziege...@apache.org wrote:
 2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:
 ...Should have both local (to the feature) and global variables?...

 Variables are currently local to a feature - do we need global variables?
 When e.g. overriding a variable from a system property it could use
 feature.VARNAME as the key...

That should work, I agree, but in your example is feature the ID of
a feature? If yes where is it defined?

 What is sling.options, does it already have a defined meaning?...
 This is a defined framework property for the sling run mode handling. It
 tells Sling's launchpad that one of the two run modes will be active, but
 exactly one...

Ah, ok - the name does not say anything about that, should rather be
sling.runmode.options? We might accept both names for now and
deprecate the old sling.options name?

 ...I think having the attributes of a section (run mode, start level) in the
 same line is more readable and understandable

Ok, that works for me as long as run mode and start level as treated
in the same way, as they are orthogonal.

-Bertrand

Re: Updates to the Slingstart Model

2014-10-01 15:19 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:

 Hi,

 On Wed, Oct 1, 2014 at 3:13 PM, Carsten Ziegeler cziege...@apache.org
 wrote:
  2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org:
  ...Should have both local (to the feature) and global variables?...

  Variables are currently local to a feature - do we need global variables?
  When e.g. overriding a variable from a system property it could use
  feature.VARNAME as the key...

 That should work, I agree, but in your example is feature the ID of
 a feature? If yes where is it defined?

 It's the feature name from the first line: [feature name=REQUIRED]

 What is sling.options, does it already have a defined meaning?...
  This is a defined framework property for the sling run mode handling. It
  tells Sling's launchpad that one of the two run modes will be active, but
  exactly one...

 Ah, ok - the name does not say anything about that, should rather be
 sling.runmode.options? We might accept both names for now and
 deprecate the old sling.options name?

 Sure we could do that - I agree that sling.runmode.options is a little bit
nicer. I don't have a strange urge to do the deprecation though :)


  ...I think having the attributes of a section (run mode, start level) in
 the
  same line is more readable and understandable

 Ok, that works for me as long as run mode and start level as treated
 in the same way, as they are orthogonal.


Yes, I agree.

Cool, it seems we have a first agreement. I'll update the implementation
with the points discussed.

Thanks

Carsten



 -Bertrand




-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Updates to the Slingstart Model

2014-09-29 23:12 GMT+02:00 Alexander Klimetschek aklim...@adobe.com:

 On 29.09.2014, at 06:36, Carsten Ziegeler cziege...@apache.org wrote:

  I'm fine with a structured text format that's not YAML, as long as
  it's diff-friendly and allows for comments. The benefit is that we can
  customize the syntax for our actual needs.
 
  Yepp, exactly. Funnily, I found YAML to verbose after experimenting with
 it

 We definitely should use JSONx that combines the awesomeness of JSON with
 the great structure of XML:

 https://twitter.com/DanHarper7/status/514822464673951744

 :)


{checking the calendar for the current datehmm it's not April}

Yeah, maybe we can find something even more verbose? :)

Carsten


 Cheers,
 Alex




-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Updates to the Slingstart Model

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

Re: Updates to the Slingstart Model

I've thought a little bit more about the model and I came up with a
slightly different syntax. A file with examples can be found here:
https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt

The previous version messed up features and run modes and made them the
same. But that's not true, a feature can have artifacts in different run
modes.
So I changed the model and now each file represents a single feature, a
feature has a name which is usually derived from the file name of the model
file.

A feature has variables that can be used for the values of settings and
configurations and also to specify artifacts.

A feature consists of run modes - the global one is the default run mode
and always active.

A run mode can have settings, configurations, and artifacts.

In the txt file, each part is introduced with a section notation, like
[configurations], [artifacts] etc.

An artifact is just a single line with the maven coordinates of the
artifact. it can have additional information like the sha1 etc.

A configuration is started with a line containing the pid or factory pid +
alias, followed by the contents of the configuration and ends with an empty
line.

Each object in the model can have comments preceding the object.

Based on this we'll have two utility methods: one for agregating a model
based on features. This is e.g. reading a directory of model files in
alphabetical order. The aggregation checks for unique variables etc.
The second utility method is merging - it merges a complete (aggregated
model) with another aggregated one. This allows for overlaying or customing.

WDYT?

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

Re: Updates to the Slingstart Model

2014-09-30 Thread Robert Munteanu

Hi,

On Tue, Sep 30, 2014 at 10:21 AM, Carsten Ziegeler cziege...@apache.org wrote:
I've thought a little bit more about the model and I came up with a
slightly different syntax. A file with examples can be found here:
https://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/model/example.txt

A feature has variables that can be used for the values of settings and
configurations and also to specify artifacts.

A feature consists of run modes - the global one is the default run mode
and always active.

A run mode can have settings, configurations, and artifacts.

In the txt file, each part is introduced with a section notation, like
[configurations], [artifacts] etc.

An artifact is just a single line with the maven coordinates of the
artifact. it can have additional information like the sha1 etc.

A configuration is started with a line containing the pid or factory pid +
alias, followed by the contents of the configuration and ends with an empty
line.

Each object in the model can have comments preceding the object.

WDYT?

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)'.

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 ?

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

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.

What about Sling Provisioning Model (SPM) ?

Carsten

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Updates to the Slingstart Model