As I mentioned last week, I had some concerns about using FileInstall for ConfigAdmin support and, more than concerns about FileInstall in particular, I didn't like the whole approach within Launchpad of "copying some files out of the JAR/WAR" and didn't want to see us continue this pattern.
I worked out a solution to this today and I'm pretty happy with it. In short... Launchpad exposes a service which allows bundles/services within the framework to access the contents of the launchpad archive (or project, in the case of the maven-launchpad-plugin) as a virtual file system. It is then trivial to create a component which uses this service to access configuration files and install them via osgi.installer. The specific steps involved were: 1) Creating a new launchpad.api bundle which contains the ResourceProvider interface [1] 2) Modifying launchpad.base to use the new ResourceProvider interface, add it to the list of system packages, and register the service. 3) Modifying maven-launchpad-plugin to use the new ResourceProvider interface. 4) Creating a new launchpad.installer bundle which contains a Component referring to the ResourceProvider service and osgi.installer. The patch can be viewed here: [2]. It looks much bigger than it is due to all of the internal changes within launchpad.base. There are also two minor changes in osgi.installer which I think should probably be made regardless. This patch includes a sample cfg file in both launchpad/builder and launchpad/testing. This was done so I could ensure that it worked in war, jar, and launchpad:run scenarios. There needs to be some kind of automated test. Note that in order for this to work properly [3], I had to introduce osgi.installer into the main pom. I'd like to get rid of the separate reactor for installer entirely, but there are still some integration test failures in osgi/it and it looks like Carsten is still working on this module. In any case, going down this path means that osgi.installer will need to be part of Sling 6 (if we want ConfigAdmin to be part of Sling 6, of course). Justin [1] Because ResourceProvider was already used within launchpad.base for this purpose, I used that name, although it's a bit odd that we have two different service interfaces named ResourceProvider. Suggestions for alternate names welcome :) [2] http://codereview.appspot.com/1953045/ [3] This is only 50% true.
