Welcome to the Eclipse platform!
The following sections discuss the issues and problems with building integrated tool suites, and how the Eclipse tooling platform can help solve these problems.
Who needs a platform?
On any given day, you can probably find an announcement about a strategic alliance, an open architecture, or a commercial API that promises to integrate all your tools, seamlessly move your data among applications, and simplify your programming life.
Down in the trenches, you're trying to apply enough import/export duct tape to let marketing say "suite" with a straight face.
Where is all this integration pressure coming from? Why is everyone trying to integrate their products into suites or build platforms to support open integration? Who needs these platforms?
End users
Let's face it. End users do not call the support line to say, "What I really need is an open tools platform."
But they do ask why your product doesn't integrate with their other tools. They ask for features outside of the scope of your application because they can't get their data to a tool that would do the job better. They run into problems importing and exporting between different programs. They wonder why their programs have completely different user interfaces for doing similar tasks. Doesn't it seem obvious that their web site design tool should be integrated with their scripting program?
Your users want the freedom to pick the best tool for the task. They don't want to be constrained because your software only integrates with a few other programs. They have a job to do, and it's not managing the flow of files and data between their tools. They're busy solving their own problems. It's your job to make the tools work, and even better if you can make them work together.
Software developers
Meanwhile, you are slaving on your tool implementing the next round of critical features, fixing bugs, and shipping releases. The last thing you need is another emergency import feature added to your list.
Wouldn't it be nice if you could just publish enough hooks to make integrating with your tool everyone else's problem? Unfortunately, unless you work for one of the giants, you just don't have enough clout to get away with that.
The challenge
What we all want is a level of integration that magically blends separately developed tools into a well designed suite. And it should be simple enough that existing tools can be moved to the platform without using a shoehorn or a crowbar.
The platform should be open, so that users can select tools from the best source and know that their supplier has a voice in the development of the underlying platform.
It should be simple to understand, yet robust enough to support integration without a lot of extra glue.
It should provide tools that help automate mundane tasks. It should be stable enough so that industrial strength tools can build on top of it. And it should be useful enough that the platform developers can use it to build itself.
These are all goals of Eclipse. The remainder of this programming guide will help you determine how close Eclipse has come to delivering on these ideals.
What is Eclipse?
Eclipse is a platform that has been designed from the ground up for building integrated web and application development tooling. By design, the platform does not provide a great deal of end user functionality by itself. The value of the platform is what it encourages: rapid development of integrated features based on a plug-in model.
Eclipse provides a common user interface (UI) model for working with tools. It is designed to run on multiple operating systems while providing robust integration with each underlying OS. Plug-ins can program to the Eclipse portable APIs and run unchanged on any of the supported operating systems.
At the core of Eclipse is an architecture for dynamic discovery, loading, and running of plug-ins. The platform handles the logistics of finding and running the right code. The platform UI provides a standard user navigation model. Each plug-in can then focus on doing a small number of tasks well. What kinds of tasks? Defining, testing, animating, publishing, compiling, debugging, diagramming...the only limit is your imagination.
Open architecture
The Eclipse platform defines an open architecture so that each plug-in development team can focus on their area of expertise. Let the repository experts build the back ends and the usability experts build the end user tools. If the platform is designed well, significant new features and levels of integration can be added without impact to other tools.
The Eclipse platform uses the model of a common workbench to integrate the tools from the end user's point of view. Tools that you develop can plug into the workbench using well defined hooks called extension points.
The platform itself is built in layers of plug-ins, each one defining extensions to the extension points of lower-level plug-ins, and in turn defining their own extension points for further customization. This extension model allows plug-in developers to add a variety of function to the basic tooling platform. The artifacts for each tool, such as files and other data, are coordinated by a common platform resource model.
The platform gives the users a common way to work with the tools, and provides integrated management o f the resources they create with plug-ins.
Plug-in developers also gain from this architecture. The platform manages the complexity of different runtime environments, such as different operating systems or workgroup server environments. Plug-in developers can focus on their specific task instead of worrying about these integration issues.
Platform structure
The Eclipse platform itself is structured as subsystems which are implemented in one or more plug-ins. The subsystems are built on top of a small runtime engine. The figure below depicts a simplified view.
The plug-ins that make up a subsystem define extension points for adding behavior to the platform. The following table describes the major runtime components of the platform that are implemented as one or more plug-ins.
Platform runtime |
Defines the extension point and plug-in model. It dynamically discovers plug-ins and maintains information about the plug-ins and their extension points in a platform registry. Plug-ins are started up when required according to user operation of the platform. The runtime is implemented using the OSGi framework. |
Resource management (workspace) |
Defines API for creating and managing resources (projects, files, and folders) that are produced by tools and kept in the file system. |
Workbench UI |
Implements the user cockpit for navigating the platform. It defines extension points for adding UI components such as views or menu actions. It supplies additional toolkits (JFace and SWT) for building user interfaces. The UI services are structured so that a subset of the UI plug-ins can be used to build rich client applications that are independent of the resource management and workspace model. IDE-centric plug-ins define additional function for navigating and manipulating resources. |
Help system |
Defines extension points for plug-ins to provide help or other documentation as browsable books. |
Team support |
Defines a team programming model for managing and versioning resources. |
Debug support |
Defines a language independent debug model and UI classes for building debuggers and launchers. |
Other utilities |
Other utility plug-ins supply function such as searching and comparing resources, performing builds using XML configuration files, and dynamically updating the platform from a server. |
Out of the box
Out of the box - or off the web - the basic platform is an integrated development environment (IDE) for anything (and nothing in particular).
It's the plug-ins that determine the ultimate functionality of the platform. That's why the Eclipse SDK ships with additional plug-ins to enhance the functionality of the SDK.
Your plug-ins can provide support for editing and manipulating additional types of resources such as Java files, C programs, Word documents, HTML pages, and JSP files.
