Hi, atm we have at least two places for configuration of a Sling application: the provisioning model and sling.properties. I think we should try to reduce this to a single place, the provisioning model.
Looking at what we have in sling.properties atm I see basically four categories: - OSGi framework properties - these can easily be moved in the provisioning model - definition of core packages. This includes the jre packages as well as the packages provided by the OSGi framework. This is usually already defined by the OSGi framework and there is actually no need to redefine this. So we can drop these completely. We just have to make sure to provide the launchpad api in case launchpad is used to start the instance. But this can easily be done within launchpad. - the more magic part for bootdelegation which checks for a class/package and if that is available from the environment, packages are added to bootdelegation. Not sure how to handle this yet. - includes like the default of sling_install.properties. If we consider that the provisioning model is the source of truth I don't think this is needed So overall, getting rid of sling.properties reduces the places of configuration and simplifies things WDYT? PS: I don't think this is something for Sling 9 :) Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
