Harnessing Eclipse features

How to use the Eclipse feature to customize Eclipse behavior

It's interesting to build a plugin: You start writing code and creating the tools you want. Copy the plugin to eclipse or the \plupgins directory in an Eclipse-based product, which is available in the Eclipse Runtime environment. When you use Eclipse again, the plugin will be found, and it will be available in the Run-time configuration, after the platform startup process.

But who knows or cares that your plugin joined in? Can the user understand what tool you are providing? Can they disable, patch, or manage your components through Eclipse? The answer is obviously negative. The plug-in itself is only a plug-in, not a fully integrated component with the Eclipse platform.

Functional Parts Packaging Plug-ins
If there is no functional components, plug-ins are difficult to control, in layman's parlance, the plug-in is not part of the functional components are not managed plug-ins. The startup process for the Eclipse platform includes a configuration step. If a new plugin is copied to the \plugins directory, or otherwise makes Eclipse available at startup, the configuration process finds it, but only notifies you by flashing the splash icon for the new plugin two times. Eclipse discovers a new plug-in because the configuration checksum for the current workspace in the \.metadate\.config\platform has changed; Because you did not provide the platform with a feature that can guide the user to make configuration changes, eclipse This change can only be prompted by Splash-flash. By packaging your plug-in as one (or two) feature, you will gain the following benefits:

List the prerequisites required by your component (in the Feature.xml file) during the Eclipse configuration process

Enables your component to be managed as an active part of the Eclipse configuration

Create tag information so that users who use the Run-time environment can identify your component and use a welcome page to inform users of the functionality provided by your feature (in the Welcome.xml file that is associated with your functional part)

You can modify your components with the Eclipse Update Manager

Do not wait until your plug-in development is complete and then package as a functional part. The design results reflected in the feature definition will affect how you build your plug-in. For example, most Eclipse components have UI features and core (not UI) functional components. If your plug-in is not divided by this method, you may consider redesigning them immediately. A feature can also be used to automatically compile and process referenced plug-ins.

Main feature identifies a product (but you have control)

Although there are many functional parts, only one feature is under control when you start Eclipse. This main feature determines the product identification and other run-time behavior, including identifying the name and the diagram associated with the Run-time platform, and redefining options for the default property values for all Plug-ins. As you can see in the following definition of your own global properties, this powerful option allows you to customize your own Eclipse settings.

Feature Building Plug-ins (if you allow them)

The plug-in development environment (PDE) automates most of the work of preparing functional parts and Plug-ins for a complete run-time environment. See the article in Eclipse.org, "PDE Generation Plug-in". These basic steps were also involved as an exercise in the Java Developer ' s Guide to eclipse, and following that exercise you can build and identify the plug-ins you already have. If you have a feature and understand how PDE helps you build Plug-ins and features, you can build a feature and then let it build all the relevant plug-ins at the same time. The build Control strategy (Bin.excludes and Bin.includes) will be discussed later in the strategy for building the feature parts using PDE. These strategies complement the eclipse.org article and the Java Developer ' s Guide to Eclipse book.

Platform Configuration Management

Understanding the requirements of the functional components helps to understand how they manage the content available in the active configuration.

startup process

If it's a freshly decompressed Eclipse platform, it will happen when you start Eclipse.exe:

Installation may have completed

If a workspace already exists, there will be a. metadata\.config\platform.cfg configuration file.

If you are installing Eclipse in a regular manner, you must run the eclipse-initialize command to generate a default initialization profile, placed under the Eclipse\.config directory. This will no longer show the Completing the Install icon when Eclipse starts with a new workspace.

Locate the Java Runtime Environment (JRE). By default, Eclipse looks for the EXLIPSE\JRE subdirectory first. If it is not found, Eclipse will look for the Java runtime environment registered in the system.
Note: The-VM dir-location parameter can be used to specify a different JRE.

The configuration is created as part of the new workspace. The new workspace usually has no configuration, so you'll see an icon before the real splash icon informs you that Setup is complete.

Process the features and plug-ins that are registered with Eclipse and create checksums that will be used to detect changes later. These features and Plug-ins are either located in the current Eclipse\features directory and the Eclipse\plugins directory, or in the eclipse\ specified by the link file ... Directory structure.

Once Eclipse is started, the active configuration definition is included in the. metadata\.config\platform.cfg file.