Use the class path container to simplify the eclipse class path

 

Introduction to class path containers

A classiclink container is an effective method for managing project resources. It can allocate project resources to a logical classiclink entry. Whether you know it or not, you may have used a class path container. The most recognized class path container by Java developers is JRE system library. Each Java project has a JRE system library in the class path. Other well-known class path containers include JUnit and plug-in dependencies, which are included in the basic Eclipse project and the web app libraries container, which is a web tools project.
(WTP) is an integral part of the dynamic Web project type. Before implementing our own class path container, let's review the various types of class path entries.

Various types of classiclink entries

Each Java project contains a. classpath file that defines the project class path. This file is usually not edited manually, but created and modified by the jdt plug-in when the user changes the Java build path attribute of the project. Each entry in the class path has
kindAttribute andpathProperties, and other optional properties related to the type. The order in which entries appear in files determines their order in the project's class path. Before continuing to learn, you can do a good job: Create a Java project, try to modify the Java build path attributes, create entries, and modify the original default entries. the classpath file, as shown in Listing 1.

Listing 1. show examples of all entry types. classpath File

<?xml version="1.0" encoding="UTF-8"?><classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="lib" path="lib/derby.jar" sourcepath="lib/derby-src.jar"/> <classpathentry kind="var" path="ECLIPSE_HOME/startup.jar"/> <classpathentry combineaccessrules="false" kind="src" path="/bar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/></classpath>

Listing 1 shows six class path entries marked as fiveType. In the underlying eclipse Java model, eachorg.eclipse.jdt.core.IClasspathEntryType representation. This type is divided into entries (Entry-by-entry)TypeAnd directory (content)Type. DirectoryTypeYes for most entriesTypeDefined, it is the source code (org.eclipse.jdt.core.IPackageFragmentRoot.K_SOURCE) Or binary code (IPackageFragmentRoot.K_BINARY). In
In eclipse v3.2,IClasspathEntryThe interface defines five constants to reference class path entries.TypeBut it is different from the five types marked in Listing 1. In fact, one type shown in Listing 1-that is
output-It is not definedIClasspathEntryAnd the other-src-Shown twice in Listing 1, because
IClasspathEntryThey are represented as different constants. This is hard to understand, but let's ignore this first, starting from the beginning of the file.

Project source folder

The first entry in Listing 1 has
kind="src"Andpath="src". This indicates that the project has a source folder located in the project root directory.srcDirectory. It implies some information about the project-obviously, it tells the Java compiler that it needs to compile the source code in the src directory. This type of entry is composed
IClasspathEntry.CPE_SOURCEConstant, and hasIPackageFragmentRoot.K_BINARYDirectoryType. After a Java project is created, the default source folder and Output Folder are inherited from the workspace preferences (see
Window> preferences> JAVA> build path). In the latest eclipse installation, the source folder and Output Folder are set to the root project folder. First in Listing 1
srcThe entry haspath="src"This is because the default source folder in the workspace is changed to SRC.

Binary Library

The second entry in Listing 1 haskind="lib"Andpath="lib/derby.jar". This indicates that there is a binary class path entry in lib/Derby. Jar under the project root directory.libThe entry references a group of class files with path attributes, which specify the directory of the. Class file or the file containing the. Class file. This entry also contains optional
sourcepathAttribute, which references the location of source code attachments.lib kindEntry by entryTypeConstant
IClasspathEntry.CPE_LIBRARYAnd hasIPackageFragmentRoot.K_BINARYDirectoryType.

Class PATH variable extension

The third entry in Listing 1 has
kind="var"Andpath="ECLIPSE_HOME/startup.jar". In this entry,ECLIPSE_HOMEIs a variable. The built-in variables provided by eclipse will reference the eclipse installation directory. You can also define custom variables for the workspace. The class path file is usually relative or absolute path to the project directory. Therefore, using variables to reference files outside the project directory to avoid absolute paths is a good practice, because absolute paths make it difficult for projects to achieve cross-Environment sharing. See
Window> preferences> JAVA> build path> classpath VariablesVariable list defined in workspace. After a variable is defined, extend the variable so that it references the file of the location of the variable to apply the variable in the build path settings.

In this example, the variables are extended by adding the eclipse startup. jar file.varThe entry is similarlibThe only difference is that before applying it to a class path, evaluate the first element in the path.varAnd
libAnother difference between entries islibAn entry can reference an archive file or a class folder, whilevarAn entry can only reference a file.var kindIs a binary entry, composed of constants
IClasspathEntry.CPE_VARIABLEAnd no directory definedType. Therefore
kind="var"Iclasspathentry must not be usedgetContentKind(). However, you must note that you can only add binary variable extensions to the class path, and to cause confusion,getContentKind()Always return for variable entries
IPackageFragmentRoot.K_SOURCE.

Primary Project

The fourth entry in Listing 1 has
kind="src"Andpath="/bar". This entry references the source code of another project in the workspace (note: the path from
/). In fact, this will add the Output Folder configured for the/bar project to the compilation class path and add any class path entries exported from the project. AlthoughkindAttribute and
"src"Same, but because it carriesIClasspathEntry.CPE_SOURCE, So this entry is composed of another entryTypeConstant, that is
IClasspathEntry.CPE_PROJECTAnd hasIPackageFragmentRoot.K_SOURCEDirectoryType.. The only difference between a classpath entry and a project is that the path property is related to the workspace.

Class path container

The fifth entry in Listing 1 has
kind="con"Andpath="org.eclipse.jdt.launching.JRE_CONTAINER". This tutorial mainly discusses this type of entry. This entryTypeConstant is
IClasspathEntry.CPE_CONTAINERAnd no directory definedType. Container entries areorg.eclipse.jdt.core.IClasspathContainerLogical reference of the implementation. The specific entries of the Integration set. The entry type is
IClasspathEntry.CPE_LIBRARYOrIClasspathEntry.CPE_PROJECT.

Category summary

The following describes the types of classless Inter-Domain Routing (classless Inter-Domain Routing) entries. The sample file is taken from
The. classpath file in Listing 1.

More

For more information, seeorg.eclipse.jdt.core.IClasspathEntryTo learn how to use these differentTypeTo set the build path through programming, see the eclipse help topic "setting the Java build path ".

Back to Top

What is a class path container?

In this tutorialClass path containerYesorg.eclipse.jdt.core.IClasspathContainer. A class path container is a logical reference to a group of class path resources.IClasspathContainerYou can define a classless path container entry set for each project. Because the set of entries is composed
IClasspathContainerIt can be either dynamic or static. If it is a static entry set, the container can return a fixed set of jar sets in the familiar directory (such as JRE system library ). Alternatively, if it is a dynamic entry set, the container may return a set of runtime jar, which will be changed based on the deployment of the server.

Back to Top

Why do I need to use a class path container?

There are many reasons for using the classiclink container. The following lists some main reasons:

Reduce confusion

You do not need to put some separate jar files under a project, but you can divide them into a container and expand the container to view the separate jar files. In this way, the real status of the screen in the Java package emerge e view can be saved.

In addition, the number of entries required for the. classpath file is reduced from multiple to one.

Portability

Because the path of the container entry uses a logical name, it does not contain information about the file system. This allows the class path entries to be transplanted to different machines, this allows you to easily share projects through source control management (SCM) (such as CVS or SVN. Variable entries also have this advantage.

Easy to manage

If you define the class path container page for the container type, you can edit the container attributes through the UI.

Dynamic Features

Dynamic features may be the most important advantage of the classless path container, because none of the other types of classless path entries have this feature. Container entries are dynamic because they are retrieved only when needed. Information about container entries is not saved in the workspace or project metadata. Only entries are required to compile and run such operations. Therefore, this provides a way to redefine class path dependencies based on any actual factors. Generally, the container can add all jar files in the project directory to the class path. In fact, this is a function of the web app libraries class path container.
The WEB-INF/lib folder of the project.