Bugzilla – Full Text Bug Listing
| Summary: | [CSS] Allow non-extension point based property handler contributions | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Bogdan Gheorghe <gheorghe> | ||||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | Bogdan Gheorghe <gheorghe> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | azerr, bernd.vogt, Lars.Vogel, ob1.eclipse, pwebster, remy.suen, tom.schindl, wbeckwith | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Bogdan Gheorghe
My suggestion would be to use DS instead of extension points this way we have a Java-API which will be called by DS in case of OSGi and by the Java-Programmer in plain Java-programs (or we make use of the service extensions provided by plain Java) (In reply to comment #1) > My suggestion would be to use DS instead of extension points Hmm... DS is very much OSGi-specific in both its logic and implementation. The extension registry itself can work without OSGi. Now, somebody would have to populate it with data and some services (like NLS support) will be reduced, but it can work without OSGi. That said, I'd question the point of this bug: it essentially sais that CSS engine needs some extensibility mechanism, and then it discounts two such mechanisms we have in Eclipse (OSGi and extensions) with the goal to create its own extension mechanism? (In reply to comment #2) > (In reply to comment #1) > > My suggestion would be to use DS instead of extension points > > Hmm... DS is very much OSGi-specific in both its logic and implementation. > > The extension registry itself can work without OSGi. Now, somebody would have > to populate it with data and some services (like NLS support) will be reduced, > but it can work without OSGi. > > That said, I'd question the point of this bug: it essentially sais that CSS > engine needs some extensibility mechanism, and then it discounts two such > mechanisms we have in Eclipse (OSGi and extensions) with the goal to create its > own extension mechanism? My impression is the other way round but well and I'd like to to get away with extension points because they force us to make our bundles singletons ... and DS works a lot better with our DI story! You can look at my 30 minutes test in bug 321486 - i know it's a very very dirty implementation. One more thing to note is that we are talking about a plug-in system and well that's exactly what OSGi is about. What can be light-weighter than OSGi? The more I think about bug 321486 and this one the more I convince myself that these requests all ask us to reinvent the wheel named OSGi. (In reply to comment #5) > these requests all ask us to reinvent the wheel named OSGi. Yes, that's my impression too. If we do want to be OSGi-free I would: - add direct access APIs to CSS that can be called by developers to add customization; - make OSGi-aware code work through those APIs; - isolate OSGi-aware code into separe package(s); and "class not found" exception handlers around calls to those methods; - make dependency on OSGi optional. That said, there is always a question of how much value there is in being OSGi-free. A few years ago, on request like this, I changed extension registry to be able to work without OSGi. This made extension registry code more complicated (this is where "registry strategy" concept started) and took some time to implement. The end result? I am not sure if there is a single product out there that uses extension registry without OSGi. I am periodically asked if the extension registry can be used without OSGi (once in a few months), but I never got any actual bugs or requests for this mode of operations. (In reply to comment #6) > (In reply to comment #5) > > these requests all ask us to reinvent the wheel named OSGi. > > Yes, that's my impression too. If we do want to be OSGi-free I would: > > - add direct access APIs to CSS that can be called by developers to add > customization; > - make OSGi-aware code work through those APIs; > - isolate OSGi-aware code into separe package(s); and "class not found" > exception handlers around calls to those methods; > - make dependency on OSGi optional. > > That said, there is always a question of how much value there is in being > OSGi-free. A few years ago, on request like this, I changed extension registry > to be able to work without OSGi. This made extension registry code more > complicated (this is where "registry strategy" concept started) and took some > time to implement. The end result? I am not sure if there is a single product > out there that uses extension registry without OSGi. I am periodically asked if > the extension registry can be used without OSGi (once in a few months), but I > never got any actual bugs or requests for this mode of operations. Hi, I have worked about this topic and I have found a solution to register the ICSSPropertyHandler for CSS engine into OSGi context and without OSGi context. More I have founded a solution into OSGi context to : * register ICSSPropertyHandler when bundle (which contains ICSSPropertyHandler) start. * unregister ICSSPropertyHandler when bundle (which contains ICSSPropertyHandler) stop. So with this last feature you can register/unregister ICSSPropertyHandler by using OSGi console by starting/stopping bundle. The fisrt thing is that I don't use plugin.xml. I' m using a custom cssengine-config.xml which declare ICSSPropertyHandler to register. I have a Bundle CSSEngine and anothers Bundles CSSEngine-handler-config1, CSSEngine-handler-config2, which contains cssengine-config.xml and register ICSSPropertyHandler into OSGi services registry. Into OSGi context : * CSSEngine-handler-config1, CSSEngine-handler-config2 load on Activator#start the cssengine-config.xml, parse it to create list of ICSSSPropertyHandler and publish the result as OSGi services. * CSSEngine bundle use OSGi services to retrieve each OSGi services registered and register the handler for the whole CSSEngine instance. When CSSEngine-handler-config1 is stopped, it unregister her ICSSPropertyHandler for the whole CSSEngine instances. When CSSEngine-handler-config1 is restarted it register her ICSSPropertyHandler for the whole CSSEngine instances. So into OSGi context, it's not the CSSEngine which search ICSSPropertyHandler but it's CSSEngine-handler-config1, CSSEngine-handler-config2 which register ICSSPropertyHandler. CSSEngine-handler-config1 -> handler -> OSGi services regisrty -> CSSEngine instances CSSEngine-handler-config2 -> handler -> OSGi services regisrty -> CSSEngine instances Into Java context, it's the CSSEngine instances which search all cssengine-config.xml founded into the ClassLoader (one ClassLoader) and parse it to register ICSSPropertyHandler. CSSEngine instances -> load -> CSSEngine-handler-config1/cssengine-config.xml -> load -> CSSEngine-handler-config2/cssengine-config.xml My work is just a POC and it doesn't use E4 CSSEngine. My test it's just a simple CSSEngine-like which display properties registered on the console every 5 sec. When you stop bundle handler config, some properties disappears from the console. Into Java app context, the whole ICSSPropertyHandler from cssengine-config.xml files are registered. Are you interested with my POC? I will try clean my work and send you my projects to see in action my explanation. Regards Angelo Created attachment 176450 [details]
POC -CSS Projects+Doc to register/unregister handler into OSGi and Pur Java context
I have attached a zip, where you will can find some projects and documentation about my idea to manage handler for CSS engine into OSGi context and Pur Java context. Please read POC-CSS.odt or POC-CSS.rtf documentation.
In this doc, you will see screen which explained each projects and the different samples (like register/unregister handlers by start/stop OSGi bundles handler config). You will find several launch to test samples.
Hope my idea will please you. My code is not commented but I hope documentation will be enough. Welcome for any suggestions!
Thank a lot.
Regards Angelo
If I understand Olegs comment right. One can use plugin.xml in a none OSGi-Env so there's no need for an extra implementation. My current position is like the one from Oleg. Our Primary Target are OSGi-Environments and if the overhead/complexity we need to introduce to support none OSGi-Envs is justifyable I'm +1 (In reply to comment #9) > If I understand Olegs comment right. One can use plugin.xml in a none OSGi-Env > so there's no need for an extra implementation. > > My current position is like the one from Oleg. Our Primary Target are > OSGi-Environments and if the overhead/complexity we need to introduce to > support none OSGi-Envs is justifyable I'm +1 Tom I had tried to study tu use plugin.xml into no OSGi context. Problem with plugin.xml is : * the bundle must be a singleton (how manage several versions of the same bundles?) * I'm not sure that the stop bundles which register extension with plugin.xml can unregister the extension. Not sure with that. Have you seen my proposition? It use OSGi services. By default you can my class CSSEngineConfigurationBundleActivator, but you could use another thing to register the services like DS or Spring DM. Config is declared into XML file cssengine-config, but you could create Java code to create the handler if you wish. (In reply to comment #9) > If I understand Olegs comment right. One can use plugin.xml in a none OSGi-Env > so there's no need for an extra implementation. > > My current position is like the one from Oleg. Our Primary Target are > OSGi-Environments and if the overhead/complexity we need to introduce to > support none OSGi-Envs is justifyable I'm +1 Hi Tom, Olegs (and other), I have investigated time to manage plugin.xml into none OSGi-Envs and it can start work well. I have implemented some org.eclipse.core.registry bundle classes to manage plugin.xml into none OSGi-Envs, and it works! So now I can use standard API wich manage extension point like : ------------------------------------------------- IExtensionPoint extPoint = registry .getExtensionPoint("org.eclipse.core.contenttype.contentTypes"); ------------------------------------------------- However there are restrictions about classpatch definition : * you must add into the classpath project (the launch) plugin.xml and META-INF/MANIFEST.MF at hand. * you must explicitly define into classpath (with Required-Bundle or with Project ClassPath) the bundle which define and add extension-point. For instance in my case I had to add org.eclipse.core.contenttype bundles with Required-Bundle in order to use this extension point into none OSGi-Envs. So with this solution, I think E4 CSSEngine will not change a lot. Just call my class which manage Extension Point which works with none OSGi-Envs. I clean my work and send you a patch with my work. Regards Angelo (In reply to comment #11) > (In reply to comment #9) > > If I understand Olegs comment right. One can use plugin.xml in a none OSGi-Env > > so there's no need for an extra implementation. > > > > My current position is like the one from Oleg. Our Primary Target are > > OSGi-Environments and if the overhead/complexity we need to introduce to > > support none OSGi-Envs is justifyable I'm +1 > > Hi Tom, Olegs (and other), > > I have investigated time to manage plugin.xml into none OSGi-Envs and it can > start work well. I have implemented some org.eclipse.core.registry bundle > classes to manage plugin.xml into none OSGi-Envs, and it works! > > So now I can use standard API wich manage extension point like : > > ------------------------------------------------- > IExtensionPoint extPoint = registry > .getExtensionPoint("org.eclipse.core.contenttype.contentTypes"); > ------------------------------------------------- > > However there are restrictions about classpatch definition : > > * you must add into the classpath project (the launch) plugin.xml and > META-INF/MANIFEST.MF at hand. > * you must explicitly define into classpath (with Required-Bundle or with > Project ClassPath) the bundle which define and add extension-point. For > instance in my case I had to add org.eclipse.core.contenttype bundles with > Required-Bundle in order to use this extension point into none OSGi-Envs. > > So with this solution, I think E4 CSSEngine will not change a lot. Just call my > class which manage Extension Point which works with none OSGi-Envs. > > I clean my work and send you a patch with my work. > > Regards Angelo Ok I have done some tests with CSS engine, and now I can apply styles into None OSGi env. The only thing I had changed into CSS engine is (CSSEngineImpl constructor) : Instead to do this : ------------------------------------- IExtensionRegistry registry = RegistryFactory.getRegistry(); ------------------------------------- I do that : ------------------------------------- IExtensionRegistry registry = org.eclipse.equinox.nonosgi.registry.RegistryFactoryHelper.getRegistry(); ------------------------------------- Where org.eclipse.equinox.nonosgi.registry.RegistryFactoryHelper is my Helper which manage into OSGi and none OSGi env. But there are some restrictions because of classpath : * I need to add "org.eclipse.e4.ui.widgets" into my classpath. * I need to add the folder "org.eclipse.e4.ui.css.core" into my classpath to load plugin.xml and MANIFEST.MF of the org.eclipse.e4.ui.css.core. If org.eclipse.e4.ui.css.core is a bundles stored into plugins, I have not this problem (because it is into my classpath). I will send you my work soon. Regards Angelo Created attachment 176652 [details]
Manage plugin.xml in NO OSGi-env (Projects + Tests + Samples with E4 CSSEngine + Docs)
Hi,
I have attached a org.eclipse.equinox.nonosgi.registry_100816.zip with my work which manage plugin.xml in NO OSGi-env (and OSGI env too). org.eclipse.equinox.nonosgi.registry project is the bundle which manage in NO-OSGi-env plugin.xml files. You will find a CVS patch for E4 CSSEngine to use it in NO OSGI-env and one sample (TestCSS) which use CSS engine in NO OSGi-env.
Zip contains a doc folder where you can find a documentation about org.eclipse.equinox.nonosgi.registry (samples are explained too). So please read "Extension Point Registry - NO OSGi-env.odt" or "Extension Point Registry - NO OSGi-env.rtf" for more information.
Hope you will like my work.
Regards Angelo
Hi, For your information, I have written an article "Eclipse Extension Points and Extensions without OSGi" at http://angelozerr.wordpress.com/2010/09/14/eclipse-extension-points-and-extensions-without-osgi/ where I explain how use "org.eclipse.equinox.nonosgi.registry" by using the sample coming from the Lars Vogel tutorial http://www.vogella.de/articles/EclipseExtensionPoint/article.html Regards Angelo This would be fantastic to have. Essentially Platform.getExtensionRegistry() could delegate to RegistryFactoryHelper.getRegistry() (or something like it) and be transparent to registry users. As for whether it would be used, we have a multi-million dollar product suite that we want to move to the eclipse platform, but would honestly need to be rewritten nearly from scrath. Instead I have spent the last couple months working through the issues to remove the circular dependencies and wiring things together using the Eclipse Registry which will be used outside of OSGi. See Oleg, your work does have users. :) Since we can't halt all development for months the plan is to iteratively update pieces to get their contributions etc from the registry and not the homegrown extension mechanism. Then we should be in much better shape to adopt the eclipse platform completely. (In reply to comment #15) > This would be fantastic to have. Essentially Platform.getExtensionRegistry() > could delegate to RegistryFactoryHelper.getRegistry() (or something like it) > and be transparent to registry users. As for whether it would be used, we have > a multi-million dollar product suite that we want to move to the eclipse > platform, but would honestly need to be rewritten nearly from scrath. Instead > I have spent the last couple months working through the issues to remove the > circular dependencies and wiring things together using the Eclipse Registry > which will be used outside of OSGi. See Oleg, your work does have users. :) > Since we can't halt all development for months the plan is to iteratively > update pieces to get their contributions etc from the registry and not the > homegrown extension mechanism. Then we should be in much better shape to adopt > the eclipse platform completely. Hi Binyan, I will be very happy if my work could be integrate in the Eclipse Platform. It should be very fantastic. Just for your information you can use today Platform.getExtensionRegistry() in your Plug-In and use in NO OSGi env by initializing in your Java main RegistryFactoryHelper.getRegistry(). Please read http://angelozerr.wordpress.com/2010/09/14/eclipse-extension-points-and-extensions-without-osgi/#SingleSourcing Regards Angelo Marking as WONTFIX, as there are currently no plans to implement that. |