Shulou(Shulou.com)06/02 Report--

This article introduces the Eclipse plug-in development of Java project model is how, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Java project model

There are many kinds of Eclipse projects, including Java project, C++ project, C# project and so on. Each project has its own characteristics. The project we most often come into contact with is the Java project, so let's focus on the Java project model.

Java models are classes used to model objects associated with creating, editing, and building Java programs. The Java model class is defined in org.eclipse.jdt.core. These classes implement the Java-specific behavior of the resource and further decompose the Java resource into model elements.

The inheritance structure diagram of the Java model is shown in figure 3.13.

Figure 3.13 inheritance structure diagram of the Java model

The subclass interfaces of IJavaElement include IMethod, IType, etc., which are not all listed here. The class structure in the Java model is relatively simple and the levels are very few.

The main methods of each interface are described below.

(1) IJavaElement

Exists: determines whether the element exists. Working with Java elements is similar to working with resource objects. When using Java elements, you are actually using handles to some of the underlying model objects. You must use exists () to determine whether the element actually exists in the workspace.

GetElementName: returns the name of the element.

GetJavaModel: returns its corresponding JavaModel, and the return type is IJavaModel.

GetJavaProject: returns the Java project corresponding to the element, and the return type is IJavaProject.

GetParent: returns the parent element, and the return value type is IJavaElement.

GetResource: returns the resource corresponding to the element, and the return type is IResource.

(2) IClassFile

This interface represents the compiled class binaries.

IsClass: determines whether it is a Java class.

IsInterface: determines whether it is an interface.

(3) ICompilationUnit

This interface represents the Java source file.

GetAllTypes: returns all the types defined in this file, and the return type is IType []. Multiple types can be defined in a Java file.

GetPrimary: returns the main type, and the return type is ICompilationUnit.

(4) IJavaModel

This interface represents the root Java element, which corresponds to the workspace. Is the parent class of all projects of a Java nature. Its effect on Java projects is similar to that of IWorkspaceRoot on IProject.

Contains: determines whether the specified resource exists.

GetJavaProject: returns the Java project with the specified name, and the return type is IJavaProject.

GetJavaProjects: returns all Java items with a return type of IJavaProject [].

GetWorkspace: return to the workspace you are in.

(5) IJavaProject

This interface represents the Java project.

IJavaElement findElement (IPath path): returns the Java element under the path path of the project.

IPackageFragment findPackageFragment (IPath path): returns the IPackageFragment under the path path of the project.

IPackageFragmentRoot findPackageFragmentRoot (IPath path): returns the IPackageFragmentRoot under the path path of the project.

FindType: the type that gets this element based on a full name, this class has several overloaded methods, and the return type is IType.

GetAllPackageFragmentRoots: returns all IPackageFragmentRoot, and the return type is IPackageFragmentRoot [].

GetOutputLocation: returns the output path, and the return type is IPath.

GetRequiredProjectNames: returns the dependent item, and the return value type is an array of strings.

SetOutputLocation: sets the output path.

(6) IPackageFragment

This interface represents the entire package or part of the package.

CreateCompilationUnit: create an ICompilationUnit, and the return type is ICompilationUnit.

GetClassFile: returns the IClassFile corresponding to the specified name, and the return type is IClassFile.

GetClassFiles: returns all IClassFile, and the return type is IClassFile [].

GetCompilationUnit: returns the ICompilationUnit corresponding to the specified name, and the return type is ICompilationUnit.

GetCompilationUnits: returns all ICompilationUnit, and the return type is ICompilationUnit [].

GetKind: determine whether this packet is a source package or an ordinary package. The return value is int. If it is equal to IPackage- FragmentRoot.K_SOURCE, it is the source package. If it is equal to IPackageFragmentRoot.K_BINARY, it is a normal package.

HasSubpackages: whether there are subpackages.

(7) IPackageFragmentRoot

This interface represents a set of packet segments and maps each segment to the underlying resource, which can be a folder, JAR, or ZIP file.

CreatePackageFragment: create an IPackageFragment, and the return type is IPackage- Fragment.

GetKind: whether this packet segment is a source code segment or a binary segment. The return value type is int. If it is equal to IPackageFragmentRoot.K_SOURCE, it is a source file segment. If it is equal to IPackageFragment- Root.K_BINARY, it is a binary segment.

GetPackageFragment: returns the corresponding IPackageFragment based on the package name.

Common tool class

(1) JavaCore (defined under org.eclipse.jdt.core package)

JavaCore inherits from Plugin and is the lifecycle manager of the JDT plug-in. However, for third-party plug-in developers, its importance is more reflected in some of the tool-class methods it provides.

IJavaElement create (IFile file): creates the corresponding Java element from the file.

IJavaElement create (IFolder folder): creates the corresponding Java element from the folder.

IJavaProject create (IProject project): get the IJavaProject corresponding to IProject.

IJavaElement create (IResource resource): creates the corresponding Java element from the resource.

IJavaModel create (IWorkspaceRoot root): get the corresponding IJavaModel from the workspace root directory.

IClassFile createClassFileFrom (IFile file): create the corresponding IClassFile from the file.

ICompilationUnit createCompilationUnitFrom (IFile file): create the corresponding ICompilationUnit from the file.

(2) JavaUI (defined under org.eclipse.jdt.ui package)

Common methods related to the interface of Java plug-ins are defined in JavaUI.

CreatePackageDialog: create a package selection dialog box and the return value is SelectionDialog.

CreateTypeDialog: create a type selection dialog, and the return value is SelectionDialog.

IEditorPart openInEditor (IJavaElement element): opens the specified Java element with the editor and returns the editor instance.

RevealInEditor (IEditorPart part, IJavaElement element): locate the element element in the editor.

Some common techniques are often encountered in plug-in development. Mastering these skills can greatly improve the efficiency of plug-in development and reduce the size of plug-ins. Here are some common tips.

(1) get the Java project from an ordinary project

The Java project is a special kind of project, and it should be noted that IJavaProject does not inherit from IProject. You cannot cast an IProject object into an IJavaProject object, nor can you assign an IJavaProject instance to an IProject variable.

How to get the Java project from the IProject project:

IJavaProject javaPoject = JavaCore.create (IProject)

How to get IProject from IJavaProject:

Call IProject getProject () of IJavaProject

(2) get all the Java projects in the workspace

We can first get all the projects in the workspace and then convert them one by one. However, this can not help but some trouble, here is a better way. IJavaModel is the root of all Java projects, and you can get all Java projects through it:

IWorkspaceRoot root = ResourcesPlugin.getWorkspace () .getRoot (); IJavaModel jModel = JavaCore.create (root); IJavaProject jProject [] = jModel.getJavaProjects ()

(3) Open the Java editor and display the specific members of the Java compilation unit

The code is as follows:

Void showMethod (IMember member) {ICompilationUnit cu = member.getCompilationUnit (); IEditorPart javaEditor = JavaUI.openInEditor (cu); JavaUI.revealInEditor (javaEditor, member);}

(4) create a com.cownew package and a Hello.java file under the project

(5) Open the [Open Type] dialog box

The following code snippet uses the JavaUI class to open the Open Type dialog box:

New ProgressMonitorDialog (parent), SearchEngine.createWorkspaceScope ()

You can also create Open package and Open Primary Type dialogs in a similar way.

(6) package the specified files

When we write some tools, we may need to package the files into jar packages, then publish them to the application server and other operations. Calling the classes provided by JDT can simplify this operation (all the classes used to package Jar are under org.eclipse.ui.jarpackager):

JarPackageData description= new JarPackageData (); IPath location= new Path ("C:/cownew.jar"); description.setJarLocation (location); description.setSaveManifest (true); description.setManifestMainClass (mainType); description.setElements (filestoExport); IJarExportRunnable runnable= description.createJarExportRunnable (parentShell); new ProgressMonitorDialog (parentShell) .run (true,true, runnable)

The parameter mainType represents the main class of the Jar package, and filestoExport is the file to be packaged.

(7) automatically set the construction path of the Java project

Some plug-ins will automatically set the required jar packages to the build path, for example, when you create a new web project using WTP's New Wizard, you will automatically put the jar packages needed for web development into the project's build path, and add plug-in dependencies to the project's build path after using PDE's "convert Project to plug-in Project" function. So how do they come true?

There are several build paths for Java projects: source folders, binary libraries, dependent projects, classpath variables, and classpath containers.

Figure 3.14 Source folder

Figure 3.15 Building dependent projects

Figure 3.16 Jar and class folder dependencies

Each different build path has different functions: the source folder is the way to build the source code, the binary library is the way to import a small number of jar packages, the dependent project is used for multi-project sub-module development, the use of classpath variables can avoid the path dependence of binary packages, and the classpath container provides convenience for the introduction of a large number of binary libraries.

JDT provides a unified interface for these different build paths: IClassPathEntry, which can be set for the project by calling the setRawClasspath method of IJavaProject.

You can see that the setRawClasspath method requires an IClasspathEntry array, and the elements in the array are each build path to be set. The JavaCore class mentioned earlier provides a series of static methods to help us generate different IClasspathEntry without paying attention to the details of the generation. Let's take a look at how different build paths are added.

① source folder. Use the JavaCore.newSourceEntry method. The following code constructs the classpath entry for the source folder src of the project MyProject:

JavaCore.newSourceEntry (new Path ("/ MyProject/src"))

② binary library IClasspathEntry. Use the JavaCore.newLibraryEntry method. The following code is the classpath entry for constructing MyProject's class file lib:

Path ("/ MyProject/lib"), null, null,false)

The following classpath entries have source code connections:

Setting the associated source code package is beneficial to the tracking debugging of the code.

③ depends on the project. Use the JavaCore.newProjectEntry method. The following code is to construct the dependency project MyFramework:

IClassPathEntry prjEntry = JavaCore.newProjectEntry (new

Path ("/ MyFramework"), true)

④ classpath variable. Use the JavaCore.newVariableEntry method. Classpath variables are global to the entire workspace and can be handled through the JavaCore methods getClasspathVariable and setClasspathVariable.

Automatic classpath variable initialization methods may be registered through the extension point org.eclipse. Jdt.core.classpathVariableInitializer to call the path variable initialization method of this class.

The following classpath entry indicates a library whose location is stored in the variable HOME. Use the variables SRC_HOME and SRC_ROOT to define the source code connection:

IClassPathEntry varEntry = JavaCore.newVariableEntry (

New Path ("HOME/foo.jar"), / / Library path

New Path ("SRC_HOME/foo_src.zip"), / / Source Code Archive path

New Path ("SRC_ROOT"), / / Source Code Archive Root path

True)

JavaCore.setClasspathVariable ("HOME", new Path ("d:/myInstall"), null)

⑤ classpath container. The classpath container is handled through JavaCore's getClasspathContainer and setClasspathContainer methods.

It is possible to register an automatic classpath container initialization method, which is passively called through the extension point org.eclipse.jdt.core.classpathContainerInitializer when the container needs to be bound.

The following classpath entry indicates the system class library container:

IClassPathEntry varEntry = JavaCore.newContainerEntry (new Path ("JDKLIB/default"), false) JavaCore.setClasspathContainer (new Path ("JDKLIB/default"), new IJavaProject [] {myProject}, new IClasspathContainer [] {new IClasspathContainer () {public IClasspathEntry [] getClasspathEntries () {return new IClasspathEntry [] {JavaCore.newLibraryEntry (new Path ("d:/rt.jar"), null, null, false) };} public String getDescription () {return "Basic JDK library container";} public int getKind () {return IClasspathContainer.K_SYSTEM;} public IPath getPath () {return new Path ("JDKLIB/basic");}, null)

All we have to do is call the appropriate method to create our classpath entries, and then set the array of these entries into the project through the setRawClasspath method. It is important to note that if we only pass the classpath entry to the setRawClasspath method, we will replace the original project build path, which is often not what we want. You can call the readRawClasspath method of IJavaProject to read the existing settings of the project, add the build path we want to set to it, and then call the setRawClasspath method to set the new project build path.

In this example, a function of "add lucene support to the project" will be implemented. After the user right-clicks on the project and selects the "add lucene support for the project" command in the menu, the plug-in will copy the lucene jar package and the source package to the project's lib directory, and add the jar package to the build path. The project structure before the addition of lucene support is shown in figure 3.17.

Figure 3.17 add the project structure before lucene support

The user right-clicks on the project, and the project structure after selecting the [add lucene support for Project] command in the pop-up shortcut menu is shown in figure 3.18.

Figure 3.18 Project structure with lucene support added

Figure 3.19 shows the build path of the project.

Figure 3.19 additional lucene package

First create a new plug-in project and add JDT-related dependencies. Then add an extension point for org.eclipse.ui.popupMenus, and if you are not familiar with how to add it, you can use the Pop-up menu wizard in the plug-in wizard.

You need to pay attention to the configuration of contribution, as shown in figure 3.20.

Figure 3.20 configuration of contribution

This plug-in works only for Java projects, so fill the objectClass with org.eclipse.jdt.core.IJavaProject;adaptable and select true;. If you generated it with a wizard, remember to empty the nameFilter. The following is the implementation code for the core class ActionAddLucene:

System.getProperty ("file.separator", "/"); JavaCore.newLibraryEntry (project .getFullPath (), project LUCENESRCJAR). GetFullPath (), null, new IClasspathEntry [oldPaths.length + 1]; LIB + FILESEPARATOR + LUCENEJAR); LIB + FILESEPARATOR + LUCENESRCJAR); IClasspathEntry entry) e.getMessage (), e))

Let's explain the key parts of the code.

IClasspathEntry [] oldPaths = javaProject.readRawClasspath ()

Read the original build path entry of the project.

IClasspathEntry luceneLibEntry = JavaCore.newLibraryEntry (project.getFile (LIB + FILESEPARATOR + LUCENEJAR). GetFullPath (), project.getFile (LIB + FILESEPARATOR + LUCENESRCJAR). GetFullPath (), null, false)

This sentence builds the jar package for lucene.

The first parameter is the location of the binary jar package, and the location of our binary jar package is the lib/lucene-1.4.3-src.jar under the project path.

The second parameter is the location of the source package corresponding to the jar package.

The third parameter is the root path of the source package, because the source root path of some source jar packages is not the root path of the jar package, such as the format of simplejta's source jar package as shown in figure 3.21.

Figure 3.21 structure of the Jar package

In this case, the second parameter is specified as "src", and the source root path of the lucene source package is the root path of the jar package, so we set this parameter to null.

The fourth parameter indicates whether to export or not, which we set to false.

(3) URL luceneLib = Activator.getDefault (). GetBundle (). GetEntry (RESOUCELIB + FILE- SEPARATOR + LUCENEJAR)

We put "lucene-1.4.3.jar" and "lucene-1.4.3-src.jar" in our plug-in's "resoucelib" directory, and when the user clicks "add lucene support for the project", copy these two files to the project's lib directory, so you need to read the two jar packages under the "resoucelib" directory of the plug-in path first.

When reading the files under the plug-in path, we can use the methods provided by the plug-in Activator class, such as calling:

You can read the file "config/my.xml" in the plug-in root directory, and the return type is java.net.URL.

(4) copyURLToFile (luceneLib, project, LIB + FILESEPARATOR + LUCENEJAR)

The file location read by Activator.getDefault (). GetBundle (). GetEntry is of type URL, and we need to copy the file corresponding to this URL to the lib of the project. Let's take a look at the backbone code of copyURLToFile:

The URL class has an openStream that opens the input stream of the file, and IFile also has a create method that accepts the input stream to create the file, so we just need to output the input stream of url to the create method of IFile.

Here we can also get the path on the disk corresponding to the url or the path on the disk corresponding to IFile, and then use Java IO to copy the file. However, this not only increases the amount of code, but also brings problems such as unable to automatically refresh because you are not using Eclipse's resource management API, so it is recommended to use API provided by Eclipse to complete this function as much as possible.

The best way to learn Eclipse plug-in development is to study the source code of Eclipse, and the most valuable reference for plug-in developers is JDT (Java Development Tools) code. I believe that after reading all the packages, you will become a master of plug-in development. The following are the contents of each major package, which readers can study selectively as needed.

On the Eclipse plug-in development of the Java project model is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.