Hi, On Thu, Sep 4, 2008 at 4:41 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: >>> URL: https://issues.apache.org/jira/browse/SLING-646...
> I like the basic idea, but I think we should not reinvent the wheel > here. The OSGi spec has the notion of deployment packages which can > contain different types of resources (bundles, configurations, etc.) > and you can register own resource processors to handle own packaging > types. Sure, it is important to support deployment packages in jcrinstall, and not hard IIUC. > So I think supporting bundles and deployment packages is enough. > Everything else can just be put into a deployment package is handled > on a more general level. IIUC what you're saying is that you wouldn't want to support reading OSGi configurations from text files found in the repository? That is supported by the Felix fileinstall stuff (IIRC), and we'd like to have similar features, that's one reason to support them. Also, there's currently no easy way for a Sling user to transfer a configuration to someone else: if you install some bundles and play with their configs from the OSGi console until they work as you'd like, the only way to send the configs to someone else is currently to do screenshots of the OSGi console. Not nice, error-prone, and that console is not very user-friendly at the moment. Having config files in the repository makes it much easier - one can copy a few bundles and configs in a repository folder, play with the configs as needed, and then simply copy those files to reproduce the behavior in another Sling instance. Deployment packages are obviously better when we're speaking of distributing collection of components that are prepared by a developer. The above scenario would provide "sling admnistrators" with a similar mechanism, without them needing any tools besides jcrinstall. Supporting configurations in jcrinstall is simple and useful, I dont see why we wouldn't do that. -Bertrand
