Felix Meschberger wrote > > I am not particularly keen on putting too much effort into something > which will be thrown almost immediately. > > Rather I would suggest for Carsten to indicate whether he will succeed > in-time for Sling 6 or whether we can be of any help to him getting this > ready for Sling 6. I think I changed/removed/refactored quiet a lot now and I'm nearly at the point of starting to add missing features and looking for long outstanding bugs/problems.
We now have a cleaner api which is nearly ready for a new release. At the moment some test cases are failing in the jcrinstaller (this seems to be caused by upgrading to the latest sling testing module with JCR 2.0 included) and two test cases in the IT module (one of them is failing for a long time, even before my changes, the other one is new). In addition as I refactored the IT tests, there are now some things untested like if the installer is idle after it has done the tasks it should do. This should be done as junit tests inside the installer module. So in short, any help in getting the tests fixed and new tests is really appreciated. I hope to start on the new stuff soon. Regards Carsten > >> >> 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. > > I can live with that. In fact, IIRC JCR Install already does this on > every bundle reastart. > >> >> 2) There is no harm in installing/upgrading bundles directly from >> (Launchpad) ResourceProvider. > > We had this before we started copying bundles into the startup folder. > So this is perfectly ok for me -- provided we still support the startup > folder for extra deployment (as used by Sakai IIRC). > >> >> 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... > > On the other hand, the content or resources is/are really provided form > inside the launchpad package (either the standalone jar or the web > application or even the launchpad plugin). > > I could live well with LaunchpadContentProvider. > > Regards > Felix > >> >> 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. >>>> >> >> > -- Carsten Ziegeler cziege...@apache.org
