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 <[email protected]> > 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 > >
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
