2014-10-01 15:19 GMT+02:00 Bertrand Delacretaz <[email protected]>:
> 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? > > 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 [email protected]
