The idea for OSGi Connect specification is that the Framework itself does not need to support Graal native image bundles. However, something like Atomos which provides a ConnectFramework to launch a Framework implementation with can support loading bundles from a Graal native image.
But that also assumes that the Framework implementation you use is able to run from a Graal native image. At the moment the Atomos project does this with Equinox, but I don't see any reason Felix could not be compiled to native also. Tom On Thu, Jan 23, 2020 at 10:42 AM Pierre De Rop <[email protected]> wrote: > +1 from me as well. > > I'm also very interested. > I did not know that Karl also worked on implementing the OSGi Connect RFC. > Karl, will it also support class loading from a Graal Substrate native > image environment ? > I ask this because I'm currently trying to adapt the Felix Connect ([1]) > for the support of native image; so maybe my work is then useless if your > upcoming framework is (or will) support Graal native image ... > > regards > Pierre > > [1] http://svn.apache.org/viewvc/felix/trunk/connect/ > > On Thu, Jan 23, 2020 at 4:31 PM Richard S. Hall <[email protected]> > wrote: > > > Sounds reasonable to me. > > > > -> richard > > > > On 1/23/20 10:08 AM, Thomas Watson wrote: > > > Hi, > > > > > > The OSGI R8 Core specification is currently being worked on by the OSGi > > > Alliance. One of the proposals is to add something called OSGi Connect > > to > > > the Core Framework specification [1] [2]. > > > > > > This specification takes much of its initial inspiration from the > current > > > Felix Connect/PojoSR project. The basic idea for OSGI Connect is to > > allow > > > content managed outside of the OSGi Framework to be represented as > > > (connected to) bundles installed inside the Framework. > > > > > > As we have been developing the OSGi Connect specification I have been > > > working on a proof of concept called Atomos [3] that implements > different > > > strategies for representing content managed from outside the Framework > as > > > bundles inside the framework. Currently Atomos can run bundles from > the > > > following environments: > > > > > > 1) Using the Java class path - Atomos will discover any bundle JARs on > > the > > > class path and represent them as installed bundles. This most closely > > > resembles what Felix PojoSR currently does I think. > > > > > > 2) Using the Java module path - Atomos will discover all modules in the > > > Module Layer hierarchy and represent them as installed bundles. This > > > includes modules that have bundle manifests as well as ones that do > not. > > > This also extends to the ability to load the framework and set of > bundles > > > from a jlink image. > > > > > > 3) Using Graal Substrate native - With additional work to configure > > native > > > compilation Atomos can enable the Framework and a set of bundles to be > > > compiled into a native image. > > > > > > Now that we are progressing the specification for OSGi R8, I would like > > to > > > contribute Atomos to an existing OSGi community where it may gain > greater > > > adoption and contribution from others. I think Apache Felix is a good > > fit. > > > My plan is to have Atomos work with any OSGi R8 Framework > implementation > > > that supports OSGi Connect and would have the tests run using both the > > > Felix and Equinox Framework to prove it continues to only use OSGi > > > specified APIs to do so. The project itself already is Apache-2.0 > > licensed. > > > > > > What to others think about contributing Atomos to Apache Felix? > > > > > > Tom > > > > > > [1] - https://blog.osgi.org/2019/09/osgi-connect-revisited.html > > > [2] - > > > > > > https://github.com/osgi/design/blob/master/rfcs/rfc0243/rfc-0243-Connect.pdf > > > [3] - https://github.com/tjwatson/atomos > > > > > > > >
