The most attractive part of eclipse is its plug-in architecture. An important concept in this system is extension points, which is the interface provided for the plug-in. Each plug-in is developed on an existing extension point, and may have its own extension point, so that the plug-in can continue development.
With plug-ins, the core part of the eclipse system is easy to start: Start the basic part of the platform and find the system plug-ins. Most of the functions implemented in eclipse are implemented by the corresponding plug-ins. For example, the wrokbench UI plug-in displays the appearance of the interface, the Resource Management plug-in completes resource management such as maintenance or project or file generation (this plug-in will be used in the second example below), and version and configuration management (VCM) the plug-in is responsible for version control, and so on. Although each of the features mentioned above is essential to the vast majority of IDE environments, eclipse has also made them a plug-in mode, and even used to develop Java program development environments (Java Development tooling, jdt) is just a common plug-in the eclipse system. The entire eclipse architecture is like a big puzzle. You can add plug-ins constantly. You can also add plug-ins to existing plug-ins. The following plug-in development example is developed on the observation window extension point in the workbench UI plug-in.
The first part of this article introduces one of the eclipse development interfaces, namely the observation window, which usually works with the editing window to display some useful information. Here we only generate a simple observation window that displays welcome information, suppose the name of the new plug-in is welcome.
Step 1: Create a Java project using the wizard. You can select File à New in the menu bar, press the wizard button in the toolbar, or right-click New in the resource window to open the wizard dialog box and create a project by default. Create a welcome. Java file in the project. The Code is as follows:
Package com. nidapeng. Eclipse. plugin;
Import org. Eclipse. SWT. Widgets. composite;
Import org. Eclipse. SWT. Widgets. label;
Import org. Eclipse. SWT. SWT;
Import org. Eclipse. UI. Part. viewpart;
Public class welcome extends viewpart {
Label label;
Public welcome (){
}
Public void createpartcontrol (composite parent ){
Label = new label (parent, SWT. Wrap );
Label. settext ("Welcome to eclipse ");
}
Public void setfocus (){
}
}
To enable normal compilation of this program, you must configure its compiling environment, that is, specify the required classpath. You can use several methods in eclipse. There are two common methods: first, select the project in the resource window or Java package window, and right-click the project, select properties from the menu, select Java build path à libraries in the Properties dialog box, and use the Add external jars function to add three packages, these are the class packages of existing Eclipse plug-ins. You can find them in the corresponding path under "Your eclipse installation path/plugins. They are runtime. jar in org. Eclipse. Core. runtime plug-in, SWT. jar in org. Eclipse. SWT, and workbench. jar in org. Eclipse. UI. The second method to specify classpath is to first import the three packages mentioned above to a project in eclipse. If it is imported to and welcome. in a project with the same Java, you do not need to specify classpath. Otherwise, you need to select Java build path à projects from the properties menu of the project, and then select the project where the three packages are located.
We also need to generate an XML file in our project. Its name must be in. xml. The Code is as follows:
<? XML version = "1.0" encoding = "UTF-8"?>
<Plugin
Id = "com. nidapeng. Eclipse. plugin"
Name = "Welcome to eclipse"
Version = "1.0"
Provider-name = "Ni Dapeng">
<Requires>
<Import plugin = "org. Eclipse. UI"/>
</Requires>
<Runtime>
<Library name = "Welcome. Jar"/>
</Runtime>
<Extension
Point = "org. Eclipse. UI. Views">
<Category
Name = "welcome"
Id = "com. nidapeng. Eclipse. plugin. category1">
</Category>
<View
Name = "Welcome to eclipse"
Category = "com. nidapeng. Eclipse. plugin. category1"
Class = "com. nidapeng. Eclipse. plugin. Welcome"
Id = "com. nidapeng. Eclipse. plugin. view1">
</View>
</Extension>
</Plugin>
There are four main tags in plugin. xml: plugin, requires, runtime, extension. The property of the plugin TAG provides the basic information of the welcome plug-in to be developed, except for name, version, provider-name, etc. The most important thing is ID, it must not conflict with the existing Eclipse plug-in ID, so we use the package name as the plug-in ID. The required plug-ins are listed in the requires label. here we need to use eclipse workbench and swt api, so the org. Eclipse. UI plug-in is imported. The runtime tag specifies the file name of the jar package where the plug-in we developed is located. The extension tag is the extension point information of the plug-in. Org. eclipse. UI. views is an extension of the observation window provided by the eclipse system. In our example, it is an observation window (view), which indicates that we are in org. eclipse. UI. the views extension point is further developed. Extension also includes two labels: category and view. In the subsequent steps of starting the welcome plug-in, we will know the meaning of these two labels. Note the uniqueness of the category and view tag IDs, and declare the Class Name of the welcome plug-in the view attributes.
In eclipse, a default visual editor is provided for plugin. XML, which can be used to complete some work during compilation of plugin. xml. If you have directly entered the source code of the plugin. xml file, you can also use this editor to verify your code. If the editor cannot be correctly read, it indicates that your plugin. XML has some problems.
Confirm weclome. java and plugin. after the XML is correct, you can use the Export command in the eclipse menu bar to change weclome. java exports it as a jar file, and its name should be the same as that of plugin. the jar files declared by runtime in XML are consistent. Export plugin. xml at the same time. The method for installing the welcome plug-in is the same as the method for installing the Tomcat plug-in described in the first part of this article: First, create a COM. nidapeng. eclipse. plug-in path, and then set weclome. jar and plugin. copy XML to this path. After that, you must restart eclipse. When eclipse is started, it will search for all the plug-ins in the plug-in path and register them (only registration, only when a plug-in is required, eclipse ). In the restart eclipse menu bar, select perspective à show view à others. In the displayed dialog box, we will find in plugin. the name attribute declared in the category label of extension in XML: Welcome. The Support Node of welcome contains the view label name attribute: Welcome to eclipse. Select it and confirm that the welcome window displays a location on Eclipse workbench. If you have performed the preceding operations but no new window is displayed, you can open the show View menu again. In this case, you should select "Welcome to eclipse" in the menu and select it.
We have completed a plug-in for the observation window, but this operation process is not very convenient for the development of a slightly complex plug-in: Every test should pack and release the code, restart the eclipse system! For this reason, eclipse provides a plug-in specifically designed for the development of plug-ins (a bit confusing): plug-in Development Environment (PDDE ). As mentioned above, this plug-in is provided by default in the release or stable version of eclipse. Therefore, if you install one of the two versions of Eclipse, you can directly perform the following steps. Next, we will use the apsaradb for MongoDB environment to develop a slightly more complex plug-in.
The first step is to create a new project, but the plug-in project in Plug-in development is not used in the Wizard. When using the Application Wizard to generate a new project, pay attention to two points: the first is that the project name of the project is the ID of the plugin, so ensure its uniqueness. here our project name is com. nidapeng. eclipse. plugin.. To further describe the Eclipse plug-in structure, in Plug-in code generators, select to generate a default plug-in using a wizard template:
Figure 6
This plug-in class generated by default is not required for the code we want. You can also create a project by generating an empty plug-in, this is just to further illustrate the Eclipse plug-in structure.
After the project is generated, our project will contain a pdeplugin. Java file, which is a plug-in class generated by default. Note that it inherits the abstractuiplugin class, while the abstractuiplugin class implements the org. Eclipse. UI. plugin interface. In fact, all Eclipse plug-ins have a corresponding class that implements the plugin interface. This class will be the main class of the new plug-in (similar to the Java class with the main () function ), it is responsible for managing the plug-in survival. In our abstractuiplugin inheritance subclass, the first and only instance of the plug-in generated in eclipse can be saved in singleton mode. Generally, in this inherited subclass, you must also implement the getdefault () method to return the instance of the current plug-in. In addition, when eclipse uses this plug-in for the first time, this main class will be the first class to be called, so we can also execute some initialization work in its code. If the plug-in needs to use preferences, dialogs or images resources, you can also use the corresponding methods in this class to obtain their instances, such as getdialogsettings (), getpreferencestore (), getimageregistry () method.
As mentioned above, pdeplugin. Java is not necessary for the following example. We do not need to modify it. In our first example, the weclome plug-in does not generate an inherited subclass of javasactuiplugin. In this case, the system automatically generates a default main class for the weclome plug-in (similar to Java class constructor, if no declaration is made, a default constructor is specified ).
The following code truly implements the functions of our new plug-in. Assume that the plug-in name is noticeview:
Package com. nidapeng. Eclipse. plugin. PVDF;
Import org. Eclipse. Core. Resources .*;
Import org. Eclipse. Core. Resources. iresourcechangeevent;
Import org. Eclipse. Core. runtime. coreexception;
Import java. util. resourcebundle;
Import org. Eclipse. SWT. Widgets. label;
Import org. Eclipse. SWT. Widgets. composite;
Import org. Eclipse. UI. Part. viewpart;
Import org. Eclipse. SWT. SWT;
Import org. Eclipse. SWT. Widgets. display;
Public class noticeview extends viewpart implements
Runnable, iresourcechangelistener, iresourcedeltavisitor {
Private resourcebundle;
Private Label label;
Private display disp;
Private string disptxt;
Public noticeview (){
Resourcesplugin. getworkspace (). addresourcechangelistener (this,
Iresourcechangeevent. pre_close
| Iresourcechangeevent. pre_delete
| Iresourcechangeevent. pre_auto_build
| Iresourcechangeevent. post_auto_build
| Iresourcechangeevent. post_change );
}
Public static iworkspace getworkspace (){
// The main class of the resourcesplugin plug-in!
Return resourcesplugin. getworkspace ();
}
Public void createpartcontrol (composite parent ){
Label = new label (parent, SWT. Wrap );
Label. settext ("Change your project status ...");
Disp = display. getdefault ();
}
Public void setfocus (){
}
// Implement the resourcechanged method in the iresourcechangelistener Interface
Public void resourcechanged (iresourcechangeevent event ){
Iresource res = event. getresource ();
Switch (event. GetType ()){
Case iresourcechangeevent. pre_close:
Disptxt = res. getfullpath () + "is about to closed! ";
Break;
Case iresourcechangeevent. pre_delete:
Disptxt = res. getfullpath () + "is about to be deleted! ";
Break;
Case iresourcechangeevent. post_change:
Try {
Event. getdelta (). Accept (this );
} Catch (coreexception e ){
E. printstacktrace ();
}
Break;
Case iresourcechangeevent. pre_auto_build:
Try {
Event. getdelta (). Accept (this );
} Catch (coreexception e ){
E. printstacktrace ();
}
Break;
Case iresourcechangeevent. post_auto_build:
Try {
Event. getdelta (). Accept (this );
} Catch (coreexception e ){
E. printstacktrace ();
}
Break;
}
Disp. syncexec (this );
}
// Implement the visit method in the iresourcedeltavisitor Interface
Public Boolean visit (iresourcedelta delta ){
Iresource res = delta. getresource ();
Switch (delta. getkind ()){
Case iresourcedelta. added:
Disptxt = "resource" + res. getfullpath () + "was added .";
Break;
Case iresourcedelta. removed:
Disptxt = "resource" + res. getfullpath () + "was removed .";
Break;
Case iresourcedelta. changed:
Disptxt = "resource" + res. getfullpath () + "has changed .";
Break;
}
Return true; // visit the children
}
// Implement the run method in the runnable interface
Public void run (){
Try {
Label. settext (disptxt );
} Catch (exception e ){
E. printstacktrace ();
}
}
}
Like the first welcome plug-in above, this new plug-in also inherits viewpart. The difference is that it implements three interfaces: runnable, iresourcechangelistener, and iresourcedeltavisitor. Runnable should be familiar with the multi-threaded interface. Iresourcechangelistener and iresourcedeltavisitor are resource interfaces in the eclipse system. Resources here refer to projects or files in eclipse. When running the noticeview plug-in below, you can add, open, or delete projects or files to trigger events in these two interfaces and display relevant information in our observation window.
In the program, the strange part is that in the resourcechanged () function, the label is not directly called as you think. the settext () method is used to display information, but disp is called. syncexec (this), where disp is a display object. This is because the thread running the resourcechanged () method is not the same thread as the eclipse main thread running the plug-in where lable is located. If the label. settext () method is called directly, an exception is thrown.
The following also needs to make some changes to the plug-in. XML in the project, mainly adding the extension point declaration:
<? XML version = "1.0" encoding = "UTF-8"?>
<Plugin
Id = "com. nidapeng. Eclipse. plugin. PVDF"
Name = "PVDF plugin"
Version = "1.0.0"
Provider-name = "nidapeng"
Class = "com. nidapeng. Eclipse. plugin. PVDF. pdeplugin">
<Requires>
<Import plugin = "org. Eclipse. Core. RunTime"/>
<Import plugin = "org. Eclipse. Core. Resources"/>
<Import plugin = "org. Eclipse. UI"/>
</Requires>
<Runtime>
<Library name = "PVDF. Jar"/>
</Runtime>
<Extension
Id = "noticeview"
Name = "Notice View"
Point = "org. Eclipse. UI. Views">
<Category
Name = "notice"
Id = "com. nidapeng. Eclipse. plugin. PVDF. category1">
</Category>
<View
Name = "Notice resource view"
Category = "com. nidapeng. Eclipse. plugin. PVDF. category1"
Class = "com. nidapeng. Eclipse. plugin. PVDF. noticeview"
Id = "com. nidapeng. Eclipse. plugin. PVDF. view1">
</View>
</Extension>
</Plugin>
This XML file is very similar to the plug-in. xml of the welcome plug-in, so we will not explain it too much here.
To run this plug-in, you can directly use the run button in eclipse. Because this project is a plug-in project, the project will automatically run in the run-time workbench mode. After running, a platform is generated that is exactly the same as the current eclipse platform. on this platform, you can directly run the noticeview plug-in to check what functions the plug-in will execute, you can also use the run-time workbench method to debug the plug-in. The process of installing plug-ins and restarting eclipse is much simpler than that of using Java development environment!
Eclipse development is not only limited to plug-in development, it can also replace the standard swing in Java for Java-based independent application GUI development. It brings obvious advantages: high speed, low resource usage, cross-platform, open code, and support from large companies.
Because eclipse is still in the development stage, I found some performance is not very stable when using it to debug the program, and some problems may occur in some places, requiring users to find some solutions. However, with the development speed of Eclipse, I believe it will not be long before its various functions will be gradually improved. At present, although eclipse has all kinds of shortcomings, it does not hide the jade. I still have a very good impression on Eclipse. The running speed and resource usage are better than ivj, and most of them are easy to operate, even at this stage, there are few major bugs, such as accidental exit. We hope that eclipse will truly achieve ivj functionality in the future. The speed of visualcafe will become a software Generator for developers!