>4. What is the use of OSGi services in e4? So far I have seen there is >an IEclipseContext which allows you to fetch services like the old >IServiceLocator in 3.x does. What about putting more services directly >into OSGi (that are not local to any part of the workbench)? I would put >my declarative services to more use depending on the workbench services >available.
Yes, that is certainly the intent: services not local to a specific part are obtained as OSGi services. OSGi services can be obtained through an IEclipseContext, and this is used in a few places in e4 (for example IWorkspace is obtained as a service in the e4 photo demo). Using the context for lookup allows overriding of how the service lookup is done. By default it will doing a regular OSGi service lookup, but more local contexts could override this to do a more specific lookup (for example adding an LDAP filter), or even provide a service implementation that isn't available in the framework service registry. Generally the services are bound to the application code by injecting a context into an object, rather than by directly referencing IEclipseContext, which avoids direct dependency on e4-specific API. There is also some use of declarative services in e4, but there are likely more places where we could take advantage of it. We're still getting the hang of this programming model, so if you see specific opportunities for using OSGi services where we currently aren't, please enter a bug report. John Philipp Kursawe <[email protected]> Sent by: [email protected] 07/22/2009 06:19 AM Please respond to E4 Project developer mailing list <[email protected]> To [email protected] cc Subject [e4-dev] Some random thoughts after browsing the e4 code base Hello all, I hope its ok for non-contributors to post on this list? I thought I might get some more information about how e4 is supposed to work (I have no idea what all this modeling is doing though) and checked out the newest HEAD. Some random thoughts I would like to share with you: 1. Why is e4 still using an (empty) Activator in almost every project? Shouldn't it be a good OSGi citizen and use the FramworkUtil.getBundle(Class) whenever the current Bundle/BundleContext is needed? Also the Activator.ID is error prone to refactoring, thats why I never use it in my own projects. A similar problem has the NLS feature of Eclipse PDE, when it creates the Messages class and puts the BUNDLE into a string rather to have NLS.initialize(Messages.class.getPackage().getName() + ".messages", Messages.class) 2. Why are you still using Require-Bundle in almost every bundle when a I-P would do just fine? And then the CSS core bundle is requiring the batik bundle which it does not use one class from, does it? 3. The CSS bundles are too tightly coupled with each other. As far as I understand the concept, there are handlers for CSS elements. Couldn't those handlers and other components that make up a CSS engine implementation be contributed by extensions? 4. What is the use of OSGi services in e4? So far I have seen there is an IEclipseContext which allows you to fetch services like the old IServiceLocator in 3.x does. What about putting more services directly into OSGi (that are not local to any part of the workbench)? I would put my declarative services to more use depending on the workbench services available. For instance, now in 3.5 I export the IWorkbench as a service myself and have my other services consume it. Similar to the ISelectionService, IProgressService and others. 5. I actually like the idea of being able to define the layout of RCP applications. Currently I have gone through great pain to have a custom view on top of each perspective that you can not close/move or whatever. It provides a kind of "startbar" with custom gradient background. See here: Please understand my points not as criticism purely, I am sure for a lot of things there are good reasons just unknown to me. Said that, I am more than willing to contribute to e4 if possible after I got more insight on the processes going on. Keep up the good work! Cheers, Phil _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
