站内搜索: 请输入搜索关键词
当前页面: 图书首页 > Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications

Section 2.2.  Inside Plug-ins - Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications

Previous Page
Next Page

2.2. Inside Plug-ins

Now that you've seen the 10,000- and 1,000-foot views of Eclipse, let's drop down to 100 feet and look at plug-ins, the basic building blocks of Eclipse. A plug-in is a collection of files and a manifest that describe the plug-in and its relationships to other plug-ins.

Figure 2-3 shows the layout of the org.eclipse.ui plug-in. The first thing to notice is that the plug-in is a Java Archive (JAR), org.eclipse.ui_3.1.0.jar. As a JAR, it has a MANIFEST.MF. The manifest includes a description of the plug-in and its relationship to the rest of the world.

Figure 2-3. Plug-in disk layout


Plug-ins can contain code and/or read-only content such as images, Web pages, translated message files, documentation, and so on. For instance, the UI plug-in in Figure 2-3 has code in the org/eclipse/ui/... directory structure and other content in icons/ and about.html.

Notice that the plug-in also has a plugin.xml file. Historically, that was the home of the execution-related information now stored in the MANIFEST.MF. The plugin.xml continues to be the home of any extension and extension point declarations contributed by the plug-in.

Eclipse 3.1 vs. 3.0

Readers familiar with Eclipse 3.0 may be surprised by some of the characterizations here. This book is written to reflect the best practices for Eclipse 3.1. In particular, Eclipse 3.1 plug-ins are delivered as JARs rather than as directories. The execution-related information formerly kept in the plugin.xml file is now in the MANIFEST.MF file. Of course, Eclipse 3.1 is fully backward-compatible with both the Eclipse 3.0 approach to plug-in definition and delivery and legacy plug-ins.

Unless otherwise stated, the remainder of the book details Eclipse 3.1.



Previous Page
Next Page