updated patchset to remove modifications to osgi.installer: http://codereview.appspot.com/1997042
On Mon, Aug 16, 2010 at 8:44 PM, Justin Edelson <justinedel...@gmail.com> wrote: > 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. >
