Hi Tom,
This is good news for me as the new capability based model will allow us to manage dependency better. Do you have more details in the current impl, on top of the R5 spec such as high level design, examples or docs describing new API or features? This will help us get a head start.
Thanks,
Stanley
Software Architect - Enterprise Solutions Group
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent: Thursday, August 30, 2012 5:55 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] New framework?
Hi Pascal,
In short, yes I have been working on re-implementing the core framework on top of a generic capability and requirements model that was introduced in the Core OSGi Framework R5 specification and the OSGi resolver specification that was released with the OSGi Enterprise R5 specification. As Pascal knows the current Equinox Framework is built upon what I call a strongly typed dependency model where the package org.eclipse.osgi.service.resolver is at the center. This equinox resolver API is quite complex and a bit cumbersome in my opinion. Over the years it has become harder and harder to maintain and adapt as new requirement types (namespaces) get defined by the OSGi alliance.
I started this effort in early summer when we thought Java Modularity was going to be released in Java 8. Java Modularity in the VM has the potential to add new dependency types and I wanted a framework implementation that would could easily prototype different dependency types. Instead of re-inventing a dependency model I decided to give the generic resource/capability/requirement model defined by OSGi R5 a try and rebase the framework implementation on that. I also decided not to implement my own OSGi Resolver implementation, but instead have chosen to collaborate with Richard Hall of the Apache Felix project and reuse the OSGi Resolver service implementation from the Felix project. This is why you will notice the occasional CQ note go by over the equinox-dev mailing list for the Felix Resolver. Overall I think the model is quite nice and I have been relatively happy with the implementation on top of this model.
So far this has largely been a side project of my own (in a branch called twatson/container). Now that Java Modularity has been pushed out to Java 9 it is not urgent to push a radically different framework implementation into Kepler in preparation for Java Modularity and OSGi inter-op. With that said, I just recently got to the point where the "New framework" is getting useful and can actually launch Eclipse. But I did "break" many things in the process. Here is just a short list and I am sure there are others:
- completely removed the disabled osgi console implementation
- completely removed the provisional composite bundle implementation, I know of some users of this but they have plans to move to OSGi Subsystems or Equinox Region Digraph.
- removed much of the provisional security service implementation, I am not aware of anyone using this.
- removed support for legacy plugin.xml support
- do not provide a PlatformAdmin service implementation, currently working on a fragment that can add it back
- all equinox framework extension hook implementations will need to be migrated to new hooks.
With that I have been able to trim off 400K from the framework implementation. A couple of weeks ago, when I got Eclipse to launch on the new implementation and I finally got all the OSGi Compliance tests to pass, I was getting tempted to push for getting the new framework implementation into the Kepler plan. But over the coarse of the past two weeks I have decided that it is not the right time. The Equinox team needs to do a in-depth investigation of the impact of such a change and start making preparations to move to the new implementation. That is why you have been seeing mention of a new framework in some of the bug reports. I have been opening up bugs and providing patches that are necessary for eclipse to function on the new implementation. My tentative plan for Kepler is to keep the current implementation but for the most part it will be in maintenance mode. I will be largely focused on getting the new framework implementation in shape and providing patches to other components in Kepler that will allow them to run on both the old and new framework implementations.
Tom
Pascal Rapicault ---08/29/2012 09:44:47 PM---Through a couple of bug reports, it looks like we are working on a new implementation of the framework. Did I get that right?
From: | 
Pascal Rapicault <pascal@xxxxxxxxxxxxx>
|
To: |
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
|
Date: |
08/29/2012 09:44 PM
|
Subject: |
[equinox-dev] New framework?
|
Through a couple of bug reports, it looks like we are working on a new implementation of the framework. Did I get that right?
Pascal
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
