Skip to main content
Jump to: navigation, search

E4/position papers/Christian Campo

< E4
Revision as of 12:04, 20 May 2008 by christian.campo.compeople.de (Talk | contribs) (New page: == Position Paper: Christian Campo == There a number of topics that I'd like to be addressed in E4 that are driven by the Riena requirements in the following areas * Development of plugin...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Position Paper: Christian Campo

There a number of topics that I'd like to be addressed in E4 that are driven by the Riena requirements in the following areas

  • Development of plugins
  • client/server split
  • Serverside Eclipse
  • Different UI

Development of plugins

I see a strong need to improve the API (as others have expressed). Can we start to remove duplicate and triple implementations of the same thing ? Preferences is the best example of that but there are others. Can we have some best practise, rules of which is the "right" implementation ? And most important, can we deprecate all the others and have a plan by when deprecatation will lead to removal ?

Use more OSGi Services instead of Singletons. Synchronize the way we deal with extensions and services. Currently everyone seems to have a strong opinion that one is better than the other. I think Extensions can and should be mapped to Java Objects so that they can be injected into any component without deeper knowledge about the platform. Once you have injection for extensions its is only a small difference whether you inject a service or an extension. i.e. Inject.service("FooService").into(myComponent).andStart(context); // inject instance of service Inject.extension("extpoint").useType(IData.class).into(myComponent).andStart(contenxt); // inject instances of extensions @see http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions

That allows us to free business code from container dependant code. So business components get things inject and dont have to deal with container specific accessors. Ease testing and so on.

Back to the top