Re: [equinox-dev] New framework?

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Hi Pascal,

I plan to get more details on the new implementation soon.  My hope is to be able to split out pieces of work that can be contributed to by others in the community.  Up to this point I have simply been working on getting the base framework up and running on the generic model.  Now that I have something kind of working I think it is time to get others involved if there is interest to do so.

(Sorry for the delay in response.  I sent that note last week and then promptly went on vacation).

Tom



Pascal Rapicault ---08/30/2012 11:09:26 PM---Thanks for your detailed answer Tom. This is indeed a great news. I will encourage you to talk about this effort more widely an

From:	Pascal Rapicault <pascal@xxxxxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date:	08/30/2012 11:09 PM
Subject:	Re: [equinox-dev] New framework?

---

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 <pascal@xxxxxxxxxxxxx>
<ecblank.gif> To:	<ecblank.gif> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
<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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev