Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Eclipse, OSGi and RCP

Notes on getting started and understanding Equinox OSGi/RCP with Eclipse

joseph jobbings

on 23 July 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Eclipse, OSGi and RCP

Rich client apps aim to provide
responsiveness and high availability at the same time as offering valuable features to a user... There are a number of popular technologies for creating 'rich' client applications: RCP, AJAX, Swing, Microsoft .Net, Flash... RCP is defined as the
minimal set of plugins required
to build a rich app org.eclipse.ui
org.eclipse.core.runtime Eclipse OSGi + RCP Eclipse's proprietary plugin was
rewritten to use OSGi
(Open Services Gateway Initiative) OSGi enables new plugins to be added,
started and stopped dynamically It's a 'component and service'
model The OSGi unit of modularisation
is called a bundle.
(OSGi 'bundle' and Eclipse 'plugin'
mean the same thing here). Bundles expose functionality as
contributions to other extensions.

Any bundle can implement and use an
OSGi service.

But Eclipse has its own 'bundle
extension point' system: bundles either
contribute to other extensions, or
define their own extension points for
other bundles to use or contribute to. OSGi bundle dependency
information lives in the
manifest (MANIFEST.MF)
file. Definitions of extensions
and extension points live
in plugin.xml Why OSGi for Java? OSGi helps achieve modularity
of software components in Java
(which wasn't ever really designed
to support modular organisation...) Java's limitations for building
modular software components results from a number of factors... Code visibility control may expose
code to third-party developers contrary to
what was intended. For example,
a Java Interface class may be the proposed
way to expose class behaviour but
there is nothing to stop a third-party using
some other class that implements the
Interface. Logical package structures in
Java contribute to this problem.
Package structures help avoid the
ambiguity caused by classes with the
same name but...that only partially supports logical code partitioning. So:
a) either lump a load of unrelated classes into the same package so that Java default and private access modifiers can be used (and classes kept hidden outside of the package), or
b) keep the logical package structure and use multiple packages which may incidentally expose non-public API. The Java classpath also prohibits good
modularity practise: code versions, dependencies
and consistency are not relevant as far as the classpath goes...
Full transcript