Thanks for your detailed answer Tom. This is indeed a great news. I will encourage you to talk about this effort more widely and openly, as this is a perfect point in time to get more ppl involved with the project (though to some extent it may even be a tad late).
Pascal On 2012-08-30, at 7:55 AM, Thomas Watson wrote: > 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 > > > > <graycol.gif>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? > > <ecblank.gif> > From: > <ecblank.gif> > Pascal Rapicault <[email protected]> > <ecblank.gif> > To: > <ecblank.gif> > Equinox development mailing list <[email protected]>, > <ecblank.gif> > Date: > <ecblank.gif> > 08/29/2012 09:44 PM > <ecblank.gif> > Subject: > <ecblank.gif> > [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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
