Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-08 Thread Tim Ellison
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-08 Thread Dalibor Topic
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-08 Thread Richard S. Hall
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-07 Thread Richard S. Hall
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-07 Thread Richard S. Hall
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-07 Thread Dalibor Topic
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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-07 Thread Matt Benson
--- 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

Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)

2005-12-06 Thread Tim Ellison
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