Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Eclipse, OSGi and RCP
Transcript of Eclipse, OSGi and RCP
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
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
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...