Concepts of the Eclipse Rich Client Platform: What It's All About
- A Community of Plug-ins
- Inside Plug-ins
- Putting a System Together
- OSGi Framework
- The Runtime
- SWT
- JFace
- UI Workbench
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Eclipse environment is very rich, but there are just a few concepts and mechanisms that are essential to Eclipse-ness. In this chapter, we introduce these concepts, define some terminology, and ground these concepts and terms in technical detail. The ultimate goal is to show you how Eclipse fits together, both physically and conceptually.
Even if you are familiar with Eclipse, you might want to flip through this chapter to ensure we have a common base of understanding and terminology. Writing RCP applications is subtly different than just writing plug-ins. You have the opportunity to define more of the look and feel, the branding, and other fundamental elements of Eclipse. Understanding these fundamentals enables you to get the most out of the platform. With this understanding, you can read the rest of the book and see how Eclipse fits into your world.
2.1 A Community of Plug-ins
In Chapter 1, "Eclipse as a Rich Client Platform," we described the essence of Eclipse as its role as a component framework. The basic unit of function in this framework is called a plug-in—the unit of modularity in Eclipse. Everything in Eclipse is a plug-in. An RCP application is a collection of plug-ins and a Runtime on which they run. An RCP developer assembles a collection of plug-ins from the Eclipse base and elsewhere and adds in the plug-ins she has written. These new plug-ins include an application and a product definition along with their domain logic. In addition to understanding how Eclipse manages plug-ins, it is important to know which existing plug-ins to use and how to use them, and which plug-ins to build yourself and how to build them.
Small sets of plug-ins are easy to manage and talk about. As the pool of plug-ins in your application grows, however, grouping abstractions are needed to help hide some of the detail. The Eclipse teams define a few coarse sets of plug-ins, as shown in Figure 2–1.
)
Figure 2–1 10,000-foot system architecture view
At the bottom of the figure is the Eclipse RCP as a small set of plug-ins on top of a Java Runtime Environment (JRE). The RCP on its own is much like a basic OS or the Java JRE itself—it is waiting for applications to be added.
Fanning upwards in the figure is a collection of RCP applications—some written by you, some by others, and some by Eclipse teams. The Eclipse IDE Platform, the traditional Eclipse used as a development environment, is itself just a highly functional RCP application. As shown in Figure 2–1, the IDE Platform requires some of the plug-ins in the Eclipse RCP. Plugged into the IDE Platform is the Eclipse Software Development Kit (SDK) with its Java and plug-in tooling and hundreds of other tools written by companies and the open source community.
This pattern continues. The general shape of the Eclipse RCP and your products is the same—they are both just sets of plug-ins that make up a coherent whole. These themes of consistency and uniformity recur throughout Eclipse.
The internal detail for the Eclipse RCP plug-in set is shown in Figure 2–2. These plug-ins form the base of your RCP applications. Here we see a set of interdependent plug-ins that provide various capabilities as noted in the callout boxes. We could have zoomed in on any of the plug-in sets in Figure 2–1 and seen the same basic structure—an example of uniformity. You are in fact free to slice and dice the RCP itself or any other plug-in set to suit your needs as long as the relevant plug-in interdependencies are satisfied. In this book, we focus on RCP applications as applications that use the full RCP plug-in set.
)
Figure 2–2 1,000-foot RCP view
Managing the dependencies is a large part of building an Eclipse application. Plug-ins are self-describing and explicitly list the other plug-ins or functions that must be present for them to operate. The Runtime’s job is to resolve these dependencies and knit the plug-ins together. It’s interesting to note that these interdependencies are not there because of Eclipse, but because they are implicit in the code and structure of the plug-ins. Eclipse allows you to make the dependencies explicit and thus manage them effectively.