Although you might think of Eclipse as a Java IDE, it comprises a number of components that act together behind the scenes in Eclipse’s workspace. A plug-in is a software tool that accomplishes a specific task in Eclipse, such as allowing you to edit an Ant file, compile a Java file, or drag and drop GUI elements. The workspace, along with the Eclipse workbench, the team component, and the help component, are all parts of the overall Eclipse platform, and serve as the foundation for plug-ins to interact with the Eclipse core software.
The Java IDE you work with is the
Toolkit, or JDT. The JDT is not an integral part of
a plug-in. Eclipse
is really composed of the Eclipse Platform, which provides support
for other tools. These tools are implemented as plug-ins, allowing
the platform itself to be a relatively small software package.
Eclipse comes with a number of plug-ins, including the JDT. Another
important plug-in is
Plug-in Development Environment (PDE), which
enables you to develop your own plug-ins. If you want to develop in a
language other than Java, you get the corresponding plug-in for that
language, and many are available.
Besides using different programming languages, you can change the
human language that Eclipse uses as well. Different languages often
are supported with what are called
fragments. Plug-in fragments are available for numerous
languages, including Japanese, Korean, German, French, Italian,
Portuguese, Spanish, and even traditional and simplified Chinese.
Knowing the parts of Eclipse is essential to working with it for anything but the most casual use. If you don’t have at least an idea of what parts do what, you’ll end up confused when you encounter the barriers between these components, which can make Eclipse’s behavior seem inconsistent. For example, when you know that the JDT is different from other plug-ins, you won’t be surprised when options available in the JDT aren’t available in other plug-ins.
The Eclipse Platform consists of several components: the platform kernel, the workspace, the workbench, the team component, and the help component. You can see an overview of these components in Figure 1-3. Plug-ins are loaded when Eclipse starts; the plug-ins also appear in Figure 1-3.
Everything starts with the platform kernel. The platform kernel is written in native code, and its job is to load the rest of Eclipse; the kernel warns you if it can’t find a workable Java installation to run the rest of the application. The kernel also loads the Eclipse plug-ins.
The workbench is Eclipse at its most basic. The workbench window displays the menus and toolbars you saw in Figure 1-2 (the menu and toolbar items that are displayed are put there by the perspective you’re currently viewing).
Although you load different plug-ins, each with different windows and menu systems, the workbench is what displays them. The workbench is designed to look like a native application, targeted to your operating system. In Linux, it looks like a Linux application, in Windows, a Windows application, and so on.
Targeting Eclipse’s graphical user interface to the operating system is a somewhat controversial issue. The workbench is built using Eclipse’s own Standard Widget Toolkit (SWT) and JFace packages (built on top of SWT), which use operating-system native components in their displays. Doing that in a Java application is still a contentious point, as you’ll see when we discuss SWT and JFace later in Chapter 8, Chapter 9, and Chapter 10.
The workspace component in Eclipse
resources, including what you store on disk. Eclipse manages your
projects, and by default each project is
managed by the workspace component
directory. You’ll learn more about
projects later in this chapter in Recipe 1.5.
Your project doesn’t need to be in the workspace directory; you can use other directories, even networked directories. To select a different location, uncheck the “Use default” checkbox when you give the name of the project to create, and fill in the directory you want to use instead.
The workspace component manages all the resources in a project, including your code. It also manages changes to your code and to other files, giving you access to a stored history of the changes and even enabling you to compare those changes graphically. The workspace also communicates with plug-ins such as the JDT, making history and file information accessible.
The team component gives you version control for your code, and it supports file sharing. If you’ve developed software in a corporate environment, you might already have worked with source code control and repositories. Code is stored in a repository and checked in or out as needed, which means the changes to the software can be tracked.
Coordinating changes that teams make to the code means you can avoid the kind of random overlapping changes that will cause utter chaos otherwise. Eclipse integrates well with the Concurrent Versions System (CVS), the de facto standard for version control (except perhaps in Microsoft shops, where Visual SourceSafe still reigns supreme). In fact, the team component can act as a CVS client, which interacts with a CVS server that maintains the code repository from which team members can retrieve code. We’re going to take a look at how this works in Chapter 6.
The help component is Eclipse’s documentation system for providing help. It’s an extensible help system; plug-ins can provide their own help, in XML-formatted form, to tell the help system how to navigate their documentation.
Eclipse is extendible via plug-ins. Plug-ins can set up their own perspectives, editors, views, wizards, and more. For example, the JDT is a plug-in that adds its functionality to what the workbench already provides. Besides using some of the more than 450 plug-ins available for Eclipse, we’re also going to build our own starting in Chapter 12.