On 8/17/10 4:20 PM, Felix Meschberger wrote:
> 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.
What is this "new File Installer" of which you speak? Is this Felix's
FileInstall or extracting BootstrapInstaller from launchpad.base and
into this new launchpad.installer bundle (or something else).
I was thinking about this some more, and if getting osgi.installer ready
for Sling 6 is really a problem, perhaps launchpad.installer can simply
include a limited subset of functionality. So much of osgi.installer
seems to be about keeping resource lists and monitoring them whereas all
launchpad.installer needs is to do this for configs (plus some extra
code for handling factory pids):
String pid = createPid(path)
Dictionary dict = parseDictionary(stream);
if (!configExists(pid)) {
createConfig(pid, dict)
}
And for bundles, we already have all the code we need in
BootstrapInstaller, so moving that logic into a separate bundle should
be straight forward enough.
But before we can do this, I apparently need to convince everyone of two
things:
1) There is no harm in doing all of our "should I install/upgrade this
bundle" checks on every startup of launchpad.
2) There is no harm in installing/upgrading bundles directly from
(Launchpad) ResourceProvider.
If we can agree on these, the implementation of bundle installation
within launchpad.installer will be a lot simpler.
>
> 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....
My initial suggestion was going to be "LaunchpadContentProvider", which
I dismissed because I didn't think Launchpad belonged in the name...
Justin
>
> 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.
>>
