Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/position papers/Christian Campo"

< E4
(alternate UI)
Line 38: Line 38:
  
 
some samples:
 
some samples:
 +
 +
[[Image:Riena1-small.jpg]]
  
 
=== Bio ===
 
=== Bio ===
 
Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.
 
Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.

Revision as of 17:34, 21 May 2008

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

consolidate remove duplicates

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 ?

services and extensions

Use more OSGi Services instead of Singletons. Synchronize the way we use (=API) 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(context); // 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.

client/server split

  • consider that components can lie on different sides depending on the scenario
    • RAP/WTP versus RCP versus Client Server models like Riena
    • platform support for having that single session (client) versus multisession/multiserver context (server)
    • decouple components so that its gets easier to move them

improve serverside equinox when running in a WAR

While running OSGi in the embedded Jetty is great and easy, the support for WAR deployment isnt equally strong:

  • build war from product
  • Tomcat plugin to run OSGi as WAR within Eclipse
  • embedded webapps run as root webapp context while WAR webapps mostly have a name

alternate UI

  • RCP UI looks like the IDE
  • is not that easy on endusers
  • while there is an option to allow "freestyle" there is certain of look that seems well established i.e. Outlook, CAETeam and others (including Riena)

some samples:

Riena1-small.jpg

Bio

Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.

Back to the top