Hi,
Sounds like an interesting approach, too.
I would really like to include the OSGi Install stuff together with
this "ResourceProvider" and the new File Installer to be included with
Sling 6. If we go the route as Justin proposed, we would probably have
to include File Installer configured to the ${sling.home}/startup
location to support existing use cases depending on the startup folder
being used to install bundles.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something "intelligent" as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names....
Regards
Felix
On 8/17/10, 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.
>
