[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] New framework?
- From: åé <fyaoxy@xxxxxxxxx>
- Date: Fri, 31 Aug 2012 14:23:09 +0800
- Delivered-to: firstname.lastname@example.org
Great news 2!
I hope I can as soon checkout the new version. Maybe It will kill may idea from the scratch, which have some times:)
At the moment, A point I weighted, is the description language.
IMV, The ini rfc not a right option!
Someone do more true consideration about it?
I memtioned a strutured language before, called ON(Object Notation), more mature.
If interested, I will happy to talk about it.
2012/8/31 Pascal Rapicault <pascal@xxxxxxxxxxxxx>
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).
On 2012-08-30, at 7:55 AM, Thomas Watson wrote:
Hi Pascal,<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?
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.
Pascal Rapicault <pascal@xxxxxxxxxxxxx>
08/29/2012 09:44 PM
[equinox-dev] New framework?
equinox-dev mailing list