Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A brief tour of "Hello World"
"Hey, wait a minute, you promised no 'Hello, World'!" True, but we do need to cover a little about Eclipse's underpinnings before getting to the really interesting things. So if you have never written your own extension to Eclipse, please join me in a quick tour of the Eclipse architecture and plug-in development environment. Otherwise, skip to the next section. On with the tour!
In essence, Eclipse is a collection of loosely bound yet interconnected pieces of code. How these pieces of code are "discovered" and how they discover and extend each other captures the fundamental principles of the Eclipse architecture.
)
Figure
2. Eclipse Platform architecture
Extension versus Extension Point
Be aware that the XML tags for these two are quite similar. An extension point declares the availability of a plug-in's functionality to other plug-ins and is denoted by the <extension-point> tag. An extension uses a previously defined extension point and is denoted by the <extension> tag having the point attribute naming the extension point it wishes to use.
These functional units are called plug-ins. The Eclipse Platform Runtime, shown in Figure 2, is responsible for finding the declarations of these plug-ins, called a plug-in manifest, in a file named plugin.xml, each located in its own subdirectory below a common directory of Eclipse's installation directory named plugins (specifically <inst_dir>\eclipse\plugins). From these files, it builds at startup a global in-memory registry, called the plug-in registry, from which a given plug-in can determine at runtime what other plug-ins wish to extend it. A plug-in that wishes to allow others to extend it will declare an extension point. This is a sort of "power strip" for a plug-in that others can take advantage of by declaring an extension to it.
Returning to our example, the mission then is to decide where to "plug into" Eclipse by finding the appropriate extension point for our needs. Fortunately, once you have used Eclipse for a while, you know a surprising amount about what is available, perhaps without realizing it. This is because what you see in the Eclipse user interface and what is modeled by the classes that make up the Eclipse plug-ins often correspond nearly one-for-one to each other. Figure 3 makes this point clearer:
)
Figure
3. Views and their models
Here we see an ordinary progression of user interfaces starting from the lowest common denominator on the right, the file system contents shown by a dir command in a Command Prompt window, continuing to a highly specialized view, that of the JDT's Package Explorer on the left. From a user interface perspective, all these views are visualizing a representation of the same "model," namely some files. As Eclipse users, we naturally expect the two Eclipse views to present us different ways of looking at the same thing simultaneously: the Navigator shows a specialized view of a portion of the operating system files (Eclipse's workspace), while the Package Explorer shows us some of the same files organized and presented in a way that is more natural and efficient for a Java programmer.
Seeing how the Eclipse user interface reflects its underlying model and how its models build upon each other gives us an important clue about how we can find the best place to "plug in" our extension. The Eclipse interface names shown below the views, IFile and ICompilationUnit, are just two examples of the interfaces we can expect from the model that makes up Eclipse. Since they so often correspond with what is shown in the user interface, you already have an intuitive appreciation for what's available programmatically.
That is Part I of our tour. Part II is a look at our developing solution. Rather than present the solution and explain it piece-by-piece, wouldn't it be more interesting to discover some of it? Let's start with some questions related to the problem at hand: Extending the JDT with our own method visibility refactoring capability.