Dalibor Topic wrote:
The interface in the Wiki is going to be implemented by the Apache
Harmony class of VMs, and there specifying the need for JNI, etc. is OK.
Agreed.
I believe you're talking about that interface which is specific to
Apache Harmony class of VMs and the Apache Harmony class
Tim Ellison wrote:
Dalibor Topic wrote:
Agreed -- and if we agree on using OSGi bundles as the technology for
generic class library interop then I think we simply need to agree on
the small number of non-JSE API dependencies between the bundles to
allow for component interop.
+lots:)
I'm
Dalibor Topic wrote:
Thanks for the explanation, Richard. One last question: are the
bundles/packages made for R4 loadable with R2/R3, i.e. do osgi
implementations ignore attributes they don't understand, for example?
Bundles for R2/R3 will run on R4. It is possible to make an R4 bundle
Dalibor Topic wrote:
Tim Ellison wrote:
Dalibor Topic wrote
Finally, we'd need to have our own, ASLv2 licensed OSGi implementation.
I am not sure if there is one, but I hope Geir knows more.
We are in luck:
http://incubator.apache.org/projects/felix.html
Yay!
and
Dalibor Topic wrote:
In terms of using a minimal OSGi environment for partitioning and
management of class library parts, what differences would be relevant
between R2/R3/R4?
Between R2 and R3, not much...you can pretty much consider those two
equivalent.
R4 adds some considerable
Tim Ellison wrote:
Dalibor Topic wrote:
Just to be clear, the kernel classes are VM-dependent types that are not
typically reusable since the VM typically will 'know' the shape of the
class/instances. I think it is useful to minimize that set.
Yeah, I think we were talking past each
--- Dalibor Topic [EMAIL PROTECTED] wrote:
[SNIP]
The wonderful part of that story is that noone needs
to share any code
of any component: how VMs implement the bootstrap
set of classes, which
OSGi implementation they chose, if they use JNI or
avian carrier
pidgeons :) fails to matter, and
Dalibor Topic wrote:
There is a core set of classes required to bootstrap the OSGi framework
code. The trick is to bring up enough classes to implement the
framework, then retrospectively apply the framework rules to those
classes. By the time the framework is instantiated and ready to load
new