In order to create Eclipse components for composite applications, it is helpful if not mandatory to understand some basic concepts of the Eclipse platform which are explained in this topic.
Since release 8, IBM Lotus Notes is built on Eclipse, a powerful open-source, Java-based platform for application development. The Eclipse platform is highly modular and is made up of a set of plug-ins, i.e. structured bundles of code and/or data that contribute function to the system. To build an Eclipse component for composite applications one actually has to create an Eclipse plug-in.
Note: In this topic, we mainly focus on explaining basic concepts related to Eclipse. The fact that Notes is also based on IBM Lotus Expeditor is not further discussed here.
Eclipse Platform vs. Eclipse IDE
There is also an Eclipse IDE (Integrated Development Environment, precisely called the Eclipse SDK), which itself is based on the Eclipse platform. The Eclipse IDE offers powerful tools for developing software in many programming languages. For creating Eclipse components for composite applications, the Java-based plug-in development feature of the Eclipse SDK (called Plug-in Development Environment or PDE) provides all necessary tools.
Hence, to create an Eclipse component for composite applications, one uses the Eclipse IDE to develop a Java-based Eclipse plug-in.
The Eclipse platform
The Eclipse platform has the following structure (image taken from http://www.eclipse.org):
The main platform consists of several subsystems which are basically sets of plug-ins. It is open to user-defined plug-ins (depicted as "New Tools" in the image above) which can provide new functionality to an Eclipse-based application like IBM Lotus Notes 8. For getting started with the development of Eclipse plug-ins to be used as components in composite applications, it is sufficient yet crucial to have a basic understanding of the workbench, the anatomy of plug-ins and the platform runtime architecture.
The Eclipse platform uses the model of a common workbench to integrate the plug-ins from the end user's point of view. Basically, the workbench is the collection of UI elements that are visible to the user and is just a frame that can present various visual parts.
Note: Often, the term workbench is also used for the graphical presentation of the Eclipse IDE/SDK to the user.
The workbench UI window usually consists of several parts. In terms of composite application, the most important parts are views which in turn are placed on a page.
Inside the workbench window, you'll find one page that groups several (view) parts. Views provide information about some object that the user is working with in the workbench. Often (but not always), Eclipse components for composite applications involve view functionality and are thus presented to the user as a specific view. Views often change their content as the user selects different objects in the workbench - in terms of composite applications this would signify that some components reacted to changes that occurred in other components they are wired to.
Plug-ins are essentially the building blocks of the Eclipse platform providing the actual functionality of any application built on Eclipse. From a technical perspective, an Eclipse plug-in consists of a set of files including all the necessary Java code as JAR (Java archive) library which implements its functionality plus some meta data files that specify how the plug-in integrates into the Eclipse platform, called plug-in manifest. When developing a plug-in, Eclipse's Plug-in Development Environment (PDE) simplifies the work with these files and usually only few things must be changed manually by using file editors.
A plug-in can contribute new functionality to the platform by adding extensions to extension points declared by other plug-ins.
Extensions: Plug-ins can contribute functionality to the Eclipse platform and/or to other plug-ins. This behavior is called an "extension" because the plug-in "extends" some functionality of another plug-in or of the platform itself. The functionality to be extended has to be provided as an extension point.
Extension points: The Eclipse platform and any plug-in can declare extension points which are then used by other plug-ins for adding functionality. Information about all available extension points is maintained in the platform's central plug-in registry as created during the startup of the Eclipse-based application.
For example, the workbench - which is also a plug-in and comes with the Eclipse platform - declares an extension point for user preferences. Any plug-in can contribute its own user preferences by defining extensions to this extension point provided by the workbench plug-in. Analogously, it can also provide extensions points to be used or extended by other plug-ins as well.
Both extensions and extension points of a plug-in are defined in its plug-in manifest, specifically in the file plugin.xml. Again, the Plug-in Development Environment (PDE) as it comes with the Eclipse IDE offers handy tools to inspect and modify the plug-in manifest including its plugin.xml. When a plug-in manifest file (e.g. plugin.xml or MANIFEST.MF) is opened in the PDE, a dedicated editor is displayed:
Several tabs on the bottom of the editor window provide editors for the plug-in's extensions and extension points. Also, the sources of files like plugin.xml and MANIFEST.MF can be inspected and edited.
When an Eclipse-based application (like Notes 8) is launched, its inherent Eclipse platform runtime manages the startup process during which an in-memory registry of all available plug-ins is built. All extensions are matched to their corresponding extension point declarations. Then, while the application is running, the platform runtime is responsible for activating any required plug-in and for the life cycle management of plug-ins including adding, updating or removing plug-ins.
Since version 3.0, the Eclipse platform runtime is an implementation of the OSGi Service Platform.
The technology on which Eclipse is based is called OSGi (Open Services Gateway Initiative) Service Platform - a universal middleware platform for the loose coupling of individual software modules which are called bundles. Basically, a bundle is a JAR file that contains resources most of which resources are usually Java classes. A mandatory manifest file describes the contents of the jar file representing the bundle and provides information about the bundle in terms of the OSGi platform. Thus, a bundle is a JAR file with additional OSGi specific information which allows the bundle to be used in the OSGi runtime or container. Inside the JAR, the manifest file is named META-INF/MANIFEST.MF.
In terms of Eclipse, a plug-in is actually an extended bundle, i.e. while based on the OSGi bundle methodology, an Eclipse plug-in adds some extra information to it. That is why often an Eclipse plug-in is also called a bundle, which is not precisely correct.
Sometimes, it is necessary to take OSGi in account, especially for debugging Eclipse components using the OSGi console which gives access to the OSGi runtime in Eclipse. There is another topic in this wiki that describes how to use the OSGi console.
The Eclipse documentation contains many articles which are available online under http://www.eclipse.org/articles/. The following articles are useful for getting more information about the Eclipse platform and the plug-in technology:
For getting started with the plug-in development process in terms of composite applications, the topic "Developing an Eclipse component for Notes 8" describes how a simple plug-in to be used as Eclipse component can be created from scratch.