Hi Harald, read some comments inline.
On Sat, Dec 10, 2011 at 12:17 PM, Harald Wellmann < hwellmann...@googlemail.com> wrote: > I've committed some changes to support Felix 4.0.0-4.0.2 in Pax Runner, > see > http://team.ops4j.org/browse/**PAXRUNNER-410<http://team.ops4j.org/browse/PAXRUNNER-410> > . > > I'm not so sure about the role of the <packages> list in the platform > definitions, e.g. org.ops4j.pax.runner/pax-**runner-platform-felix/src/** > main/resources/META-INF/**platform-felix/definition-4.0.**2.xml > > This appears to be the list of org.osgi.* packages and versions exported > by the system bundle, which includes some new ones introduced in OSGi Core > 4.3.0. > > Pax Runner uses this list to build the org.osgi.framework.system.**packages > property in the generated config.ini for Felix. > > Now I'm not too intimate with Felix, but I'm wondering why Pax Runner > generates this property at all. org.apache.felix.main includes a > default.properties which sets org.osgi.framework.system.**packages and > includes the correct set of JRE packages depending on the selected > execution environment. > All i know is this was not always the case and possibly is not valid for all framework implementations. > > When config.ini does not include the system packages property, Felix falls > back to the value set in default.properties. > > Pax Runner generates the system packages from execution environment > definitions in org.ops4j.pax.runner/pax-**runner-platform/src/main/** > resources/META-INF/platform/**ee. > > What's the point in duplicating all this information in Pax Runner which > must be handled by any given OSGi framework anyway? > Again, frameworks have not been that homogenous like they are now. > > Moreover, there are subtle differences: E.g. comparing the JavaSE-1.6 > profiles from Pax Runner and Felix, the number of packages is not the same, > and Felix includes uses directives whereas Pax Runner does not. > Probably upgrade mistakes. > > So when launching Felix x.y.z under Pax Runner you don't actually get the > same framework configuration as when working with the official > distribution. This might lead to unexpected behaviour and looks a bit > dangerous to me. > > Another thing in Pax Runner's platform definitions is the set of > additional bundles. Felix requires three additional bundles for Gogo Shell > support. What about org.apache.felix.**bundlerepository, which is > included in Felix distributions but not in the platform definitions? > > Felix experts, please comment... > Not really felix expert necessarily, but profiles are a very unique thing in pax runner long before frameworks started shipping interchangeable shells. About org.apache.felix.**bundlerepository i guess this is because pax runner never shipped with it, so upgraders (working on Pax Runner, including myself) just did not care. Actually thanks to the profile concept (again which existed long before Karaf e.g. started copying a lot of it - shameless pun, no worries), it was usually about giving platforms "equal" defaults and adding features cross platform using profiles. So, that was a lot talking about "legacy". Now, i think i wrote that some time ago on the list, i see Pax Runner 1.x (as it is today) as a legacy. World has changed, frameworks are aligned (OSGi Launch API), properties are standardized etc. Thats why i personally stopped copying around the config files for every over release of felix/equinox/knopflerfish. I think it needs a Pax Runner 2 that just works with any 4.x compliant framework, perhaps requiring new major releases per 4.x OSGi Spec release, but not anything else. I thought about concepts a lot, if its worth tweaking the existing platform to create a single "OSGi 4.3" Platform (instead of a Felix 4.0 and Equinox so and so Platform) and thats about it. Or start over, not just "mock a OSGi container" (looking at the codebase you will see Pax Runner registering services like in a real OSGi container) but using a real one to bootstrap tailored OSGi VMs (or better.. why just OSGi VMs, practically any Java VM). Things like PojoSR look like a good replacement of Pax Runners "mock osgi platform" it is built on. I have some not yet open sources spikes of this on my disk, but maybe the community can comment on those ideas first ? WDYT ? I see Pax Runner still mentioned on all kinds of "Getting Started with OSGi" Blogs & Articles, so something is useful with it i guess.. Just a few lines out of a "weekended mind" for now. Enjoy, Toni > Thanks, > Harald > > > > > ______________________________**_________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general> > -- Toni Menzel Source <http://tonimenzel.com>
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
