For configuration, I would prefer any merging and discovery of configuration files to be done outside of the framework. EclipseStarter is still contained in the org.eclipse.osgi jar only for historical purposes, but I would rather that bit of the code all live in the launcher and it is the only thing that reads the configuration file directly and installs the initial set of bundles. I'm not focusing on that bit of the launch flow right now because I think it will distract us from focusing on the actual framework implementation. Right now the framework gets configuration through standard OSGi means (using the org.osgi.framework.launch API).
EclipseStarter (and the equinox launcher) read the configuration pass it to the framework and initialize the framework. It also installs the initial bundles from the osgi.bundles list and it takes over the main thread to run the eclipse application. This is all stuff that must remain outside the actual framework implementation. And just to be clear, I don't consider EclipseStarter to be part of the Framework implementation. Tom |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Pascal Rapicault <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Equinox development mailing list <[email protected]>, | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |09/04/2012 08:34 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [equinox-dev] About the fwk rewrite | >--------------------------------------------------------------------------------------------------------------------------------------------------| 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. Pascal Tom <graycol.gif>Pascal Rapicault ---09/04/2012 06:12:46 AM---I have a couple questions about the framework rewrite: <ecblank.gif> <ecblank.gif> From: Pascal Rapicault <[email protected]> <ecblank.gif> <ecblank.gif> To: Equinox development mailing list < [email protected]>, <ecblank.gif> <ecblank.gif> Date: 09/04/2012 06:12 AM <ecblank.gif> <ecblank.gif> Subject: [equinox-dev] About the fwk rewrite I have a couple questions about the framework rewrite: - Is there a document describing the goals of the rewrite - Is there any plan to change how things work on disk? (e.g. config.ini) - Since we are sharing the resolver with Felix, have we considered simply reusing felix in its entirety? 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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
