On 2012-09-04, at 10:23 AM, Thomas Watson wrote:
I will be working on documenting the goals and design of the generic model over the coming weeks. No, I did not rework the way EclipseStarter reads config.ini. EclipseStarter is just a launcher (that ends up using org.osgi.framework.launch API). It still reads the config.ini for framework configuration and it still continues to install the initial bundles from the osgi.bundles property. I tried to keep this flow so that the new framework implementation could be boot strapped without tons of changes to the rest of Eclipse. For example, you should be able to launch a self-hosted eclipse with the new implementation from a Juno installation.
I was asking because I thought this could be a nice way to change the way files are laid out on disk to make them easier to manage (e.g. have multiple config files that are read and merged at runtime rather than one file). However this would most likely require changes to p2 and PDE which is probably way broader than the scope of the work desired here.
But I did greatly simplify how the framework stores its persistent information on disk. That is really the only part the core framework controls as far as layout on disk is concerned. All other aspects are handled by things outside of the core framework (e.g. the plugins folder the configuration/ folder etc.).
For the Felix comment. Have I thought of just using the Felix Framework as is? Sure, but I think competition is good and I think it is in the best interest of Eclipse to continue to have ownership of one of the core technologies it is running on. Also, I want to point out that the OSGi Resolver specification is a very small part of a proper OSGi Framework implementation. It is a large leap to go from using one small part of the felix project to moving completely over to the Felix OSGi Framework implementation. Also, I should point out that the Felix Framework is not currently using the OSGi Enterprise Specified Resolver service implementation. It should not be a large amount of work for them to do that but, as of right now, the OSGi Resolver service implementation in Felix is a separate bundle. Richard Hall hopes to eventually merge that implementation into the Felix framework.
I was curious since after all collaboration may have been as fruitful than co-opetition. Thanks for taking the time to answer.