Hi, On Wed, Oct 1, 2014 at 3:13 PM, Carsten Ziegeler <[email protected]> wrote: > 2014-10-01 14:22 GMT+02:00 Bertrand Delacretaz <[email protected]>: >> ...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
