Building a plug-in is the fun part: You get to write code and create the tool you want. That plug-in can then be used in an Eclipse run-time environment by simply copying the plug-in into an existing \plugins directory for Eclipse or an Eclipse-based product. When Eclipse is launched, the plug-in will be found, and if it passes platform startup processing, it will be available in the run-time configuration.

But who knows or cares that your plug-in joined the party? Will users understand what your tool has to offer? Will they be able to use Eclipse to disable, service, or otherwise manage your contribution? Absolutely not. A plug-in on its own is just a plug-in, not a tool contribution fully integrated with the Eclipse Platform.

Features package plug-ins

A plug-in gets unruly without a feature. Or, to use the common parlance, a plug-in without a feature is an unmanaged plug-in. Eclipse Platform startup includes a configuration step. If a new plug-in is copied into the \plugins directory or otherwise made known to Eclipse at startup, the configuration step notices, but only lets you know by flashing the splash image twice. Eclipse notices the new plug-in because the configuration check sum stored in the \.metadata\.config\platform.cfg file for the current workspace is different. A splash-flash is all Eclipse can do since you have not provided a feature with which the platform can guide the user through a configuration modification. By packaging your plug-ins into a feature (or two), you get the opportunity to:

• List the prerequisites of your contribution (in the feature.xml file) for use during Eclipse configuration processing.
• Manage your contribution as part of the active Eclipse configuration.
• Contribute branding information to identify your contribution to those using the run-time environment and a welcome page telling users what your feature offers (in the welcome.xml file associated with your feature).
• Potentially service your contribution using the Eclipse update manager.

Don't wait until the end of your plug-in development task to add feature packaging. Design decisions reflected in feature definitions could influence how you structure your plug-ins. For example, most Eclipse contributions have UI and core (non-UI) features. If your plug-ins are not segmented this way, you might want to consider reworking them a bit now. Features can also be used to automate build processing for the referenced plug-ins.

Back to top

Primary feature brands the product (but you have control)

There are many features, but only one is in control when you start Eclipse. This primary feature identifies product branding and other run-time behavior. This includes identifying the name and associated graphics for the run-time platform as well as the option of redefining the default preferences for all plug-ins. As you will see in Defining your own global preferences, this can be a powerful option you can use to customize your own Eclipse installation.

Back to top

Features build plug-ins (if you let them)

The PDE will automate large portions of the tasks to prepare feature and plug-in content for a full run-time environment. See the discussion in the Eclipse.org article "PDE Does Plug-ins" (see Resources). The basic steps are also documented in The Java Developer's Guide to Eclipse (see Resources) as an exercise you can follow to build and brand your existing plug-ins. Suffice it to say that if you have a feature and understand how the PDE will help you build plug-ins and features, you can build a feature and have it build all associated plug-ins at the same time. Build control strategies (bin.excludes vs. bin.includes) are discussed in Strategies for building features using the PDE. These strategies supplement what you can learn from the Eclipse.org article and The Java Developer's Guide to Eclipse.

Back to top

Platform configuration management

To understand the need for features, it helps to understand how they manage the content available in the active configuration.

Startup processing

Given a fresh unzip of the Eclipse Platform, the following happens when you start the eclipse.exe:

• A Java™ runtime environment (JRE) is found. By default, Eclipse first looks for one in the eclipse\jre subdirectory. If it's not found there, Eclipse looks for one known to the operating system.
  Note: The -vm dir-location argument can always be used to identify an alternative JRE.
• A configuration is created as part of the new workspace. New workspaces typically have no configuration, which is why you see an image that says "Completing the install" before the true splash image.
• The features and plug-ins known to Eclipse are processed, and check sums are created to detect changes in the future. This includes features and plug-ins in the current eclipse\features and eclipse\plugins directories along with the eclipse\... directory structures identified by link files.

If a workspace already exists, it will include a configuration in the .metadata\.config\platform.cfg file.

If you manage your Eclipse install like a formally installed product, you would establish a default initial configuration in the eclipse\.config directory by running the eclipse -initialize command. This allows Eclipse to start up without the Completing the install image when using a new workspace.

Once Eclipse starts, the .metadata\.config\platform.cfg file will contain the active configuration definition.

How link files extend an Eclipse installation

If you have been using Eclipse for a while or added even one new plug-in to your configuration, you know that Eclipse looks for features and plug-ins in the eclipse\features and eclipse\plugins directories. Did you know that Eclipse will also look elsewhere on the file system? If well formatted link files exist in the eclipse\links directory, these will be processed and the associated features and plug-ins (including plug-ins without referencing features) will be available in the run-time configuration.

A link file is simply any file named id.link, where id is customarily the ID of the root feature being referenced. You can still place more than one feature in the link file target, and names such as foo.link work just fine. Given a link file with this content:

path=E:/Eclipse-2.1.1/installedFeatures/Examples

Eclipse will look in the identified directory for eclipse\features and eclipse\plugins directories that have valid feature or plug-in contributions. That is, the target directory must contain an \eclipse directory. If found, the additional features and plug-ins are available in the run-time configuration or processed as new configuration changes if the link file was added after a workspace was created.

A strategy for the use of link files to customize your own Eclipse installation is discussed in Using link files to manage an Eclipse install.

Configuration updates — Adding a feature

If a new feature with referenced plug-in(s) is added to the existing \features and \plugins directories, or made known to Eclipse with a link file, the check sum change triggers configuration processing. This processing goes beyond a simple splash-flash. The new feature is processed as a configuration change and the Configuration Changes dialog is shown.

For example, the dialog in Figure 1 would be shown if you had opened a workspace with the standard Eclipse unzip and later found the Eclipse Examples and either unzipped them into the same directory tree as Eclipse or added a link file to point to where the examples were unzipped.

So, if you see a dialog like this, it is because you, an install program you ran, or someone else has modified the Eclipse installation so new or updated features are available. If the entries can be selected, you can add the change to the current configuration. If the entries are disabled, there is a configuration problem blocking the addition of the new feature. The Error Details button provides information on the configuration issue.

Configuration management notes:

• Just because there are changes pending does not mean you have to accept them now. You can leave the changes as pending for quite some time. Just deselect the entry and click Finish. To add them later, use the menu option Help > Software Updates > Pending Changes... to open the dialog again.
  
  
• Changes that have been accepted can later be disabled. Open the Install/Update perspective, then select the feature in the Install Configuration view and select Disable in the Preview view. Disabled features can be enabled again later using the same process. To see disabled features in the Install Configuration view, select the Show Disabled Features toggle.

Back to top

Feature branding identifies your contributions at run time

Eclipse allows branding for the active product and optionally for each feature included in the run-time configuration. Features do not need to be branded, and you may choose to not brand all of your features, but you should brand at least one.

Branding definitions — The job of a plug-in

The trick for adding branding is knowing where to place the definitions. You brand features, but the branding content is provided by a plug-in. This is either the plug-in with the same ID as the feature (default processing) or the plug-in identified in the feature definition (option in Eclipse V2.1.1). A feature definition in Eclipse V2.1 can define an alternate plug-in using the plugin=... attribute in the feature.xml file.

The plug-in contains both the files used to define and provide branding content.

Overview of branding content

The about.ini control file defines branding content for both product- and feature-level branding. For product branding, two things must be true:

• The feature must be defined as a possible primary feature. This means that it contains primary="true" in the feature.xml definition.
• The feature must be identified as the active primary feature. This is typically done in a product using the entry in the install.ini file in the \eclipse directory. The primary feature can also be defined at runtime using the -feature featureId startup parameter.

The easiest way to understand feature branding is to see what elements are defined in the about.ini control file and where they go in a branded product or feature (see Figure 2).

These entries apply only to product branding:

• windowImage
• appName
• aboutImage

The remaining entries are used during both product and feature branding.

Values preceded by a percent sign (%) are resolved in the about.properties file. The text defined using the aboutText key is available on the About product dialog when the feature is the active primary feature. This text is also shown for any feature when selected in the About Features dialog that can be opened using the Feature Details button.

The welcomePage identified by the welcomePage entry is opened when the feature is initially added to the run-time configuration and can always be found later using the Welcome selection dialog opened using the Help > Welcome... menu option in Eclipse.

The quickest way to build a working branded feature is to clone the entries found in Eclipse itself. The feature and plug-in with the ID org.eclipse.platform provides feature and plug-in branding. A step-by-step guide is also included in "Chapter 34, Exercise 7 of The Java Developer's Guide to Eclipse.

You can find additional detail on branding on Eclipse.org in the development resources for the Update Manager subproject (see Resources).

Back to top

Strategies for building features using the PDE

The build process is covered in the chapters on feature development in The Java Developer's Guide to Eclipse and the Eclipse.org article "PDE Does Plug-ins", but there are some other considerations, as well. Once you understand how to use the PDE to build features and their referenced plug-ins, you can automate the process.

Ant targets implemented by the PDE

Let’s begin with a summary of the function provided by the PDE. The PDE will generate build.xml files for a plugin.xml or feature.xml file. The build.xml is an Ant script that can perform different types of tasks required to prepare a plug-in or feature for the run-time platform. PDE build processing allows you to perform one or more of the following build targets for a feature or plug-in.

Feature build targets of interest:

• build.jars calls the build.jars task in the build.xml file for each referenced plug-in.
• build.update.jar calls the build.update.jar task in the build.xml file for each referenced plug-in. It also creates an Update JAR for the feature. This is the default target for the Ant script.
• build.sources calls the build.sources task in the build.xml file for each referenced plug-in.
• zip.distribution creates a ZIP file of all the files required for the feature and referenced plug-ins.
• refresh tells Eclipse to refresh the feature project and the project for any referenced plug-in.

Plug-in build targets of interest:

• build.jars calls a number of targets in the build.xml file for each run-time JAR defined for the plug-in. The called target names are the same as run-time JAR file names. These targets compile the Java code and create the JAR file that includes any resources kept in the source folder.
• build.update.jar zips all the files required in the run-time plug-in directory into a file named plugin.id_version.jar, where plugin.id and version are from the plugin.xml file. This is the default target for the Ant script.
• build.sources creates a ZIP file of the Java source based on the source folders defined for a given run-time JAR file.
• zip.plugin creates a ZIP file containing all the elements for the plug-in.
• refresh tells Eclipse to refresh the plug-in project.

Note: In feature and plug-in Ant processing, the files packaged during update JAR or ZIP processing are those required in the run-time environment. These are described in the bin.includes or bin.excludes entries in the build.properties file for the feature or plug-in and the runtime JAR files for each plug-in as defined in the plugin.xml.

To build a plug-in, you might say clean, build.sources, build.jars, zip.plugin, refresh. To build a feature, you could say clean, build.sources, build.jars, zip.distribution, refresh. You want to start with clean to force all parts to be recreated. This is often required. While Ant processing will rerun many of the required steps based on changes in the input, some changes do not trigger all the required processing. Testing shows that if you change one Java source file, the corresponding source ZIP will be updated, but the class will not be compiled and the run-time JAR will not be updated. This suggests that it is safer to clean the build outputs first so you know you are using the run-time version of the current source.

Discussion scenario

For discussion purposes, let’s describe the content for just one feature and plug-in that is necessary in the run-time configuration.

As you can see by the files names, while most belong in the run-time environment, others probably should not be included in what you share with others (for example, your design documents).

Include strategy — Identify the required bits

The easiest approach, at least initially, is to just list everything you want to package during build processing as part of your feature or plug-in in the run-time configuration. The build.properties file for each is shown below:

Exclude strategy — Identify the bits that are not required or private

An alternative approach is to list what you don't want to package as part of the feature or plug-in during build processing. This must include not only what you don't want to share but also the files and directories created by build processing (some of which are temporary). The build.properties file for this approach are shown below:

Given a feature or plug-in id value of com.your.feature.id or com.your.plugin.id, you may also need to include entries such as these when using an exclude strategy:

com.your.feature.id_1.0.0.bin.dist.zip,\

com.your.feature.id_1.0.0.jar,\

com.your.plugin.id_1.0.0.jar,\

The ZIP entry will keep the distribution ZIP from being included in either an update JAR or the distribution zip itself. The JAR entries will keep the update JAR for a feature or plug-in from being included in the distribution ZIP or the update JAR itself.

An indication of this need is when your distribution ZIP or update JAR seems larger that it should be, or keeps jumping in size, every time you run the build process. These entries would go in the appropriate feature or plug-in build.properties file.

Reaction to file or structure change

Given the options described, there are still considerations for the reaction required when a new file or folder has been added to the feature or plug-in. Let’s say you prepare your feature and plug-in for possible translation; this means you need a feature.properties and plugin.properties file for each. You would need to add a reference to the appropriate .properties file when using an include strategy, but no change would be required with an exclude strategy.

Each approach is consistent in that if you add a file to a directory, no change is required. The new file will be sent for an include approach and not sent for an exclude strategy. This is really an indication of why you might consider using specific directories for different types of files. For example, an images directory for all images used by your plug-in would be included, and a design directory for any design discussion or documentation you care to keep with the plug-in during development would be excluded.

The worst-case scenario when you forget to make a build.properties update: run-time failure or inappropriate content delivery. If you add a new file or directory when using an include strategy, it will not be available after packaging, which might cause your plug-in to fail or display the Eclipse default image (red box). If you add new file or directory when using an exclude strategy, the file or directory content will be included during packaging. Choose the approach that fits your style and offers the least risk when you forget to make an update. The choice will be based on what bothers you more: a feature or plug-in that does not run, or files in the run-time directories that others should not have seen.

Back to top

Structuring features

When developing your tool, do you consider how many plug-ins are required? The short answer could be three: One for your model or non-UI core, one for your UI content, and one or more for any help content that is provided. If you look, you will see this basic pattern repeated in Eclipse itself (jdt.core, jdt.ui, jdt.doc; debug.core, debug.ui; and so on).

One reason for making this separation is that the plug-ins that contribute UI content require different portions of Eclipse at run time than plug-ins that do not contribute UI content (org.eclipse.ui).

Including other features

Features, unless included by another feature, are configured as root features in an Eclipse configuration. By default, a root feature can be disabled or enabled by the user in the Install/Update perspective and can identify an update URL in the feature.xml file. Unless specifically permitted by a search-location definition when including a feature, only the update URL in the root feature will be processed.

By including features, you manage the structure of your package. You may also have multiple features but only brand one; the others provide structure or otherwise manage the contribution. Remember that the root feature defines the update site, although this role can be delegated to an included feature by the feature that includes it when the search-location attribute is used with a value of self both.

If you were building an Eclipse-based product, you would probably want one of your features to include the Eclipse feature tree. This is not required to perform product branding, but would allow you to either identify an alternate update site (Eclipse itself uses http://update.eclipse.org/updates ), or disable Web-based updates by not identifying an update site at all. This would ensure that the Eclipse base for your product was not updated until you packaged such updates along with your own.

Role of optional features

When including a feature in another feature, you have the option of identifying the feature as optional. The primary reason for creating this structure is to allow portions of your contribution to be disabled by the user at his request.

The configuration logic for Eclipse does not allow a new feature to be added if it has included optional features that are not present. In other words, attempt to use optional features as way of creating layers that would be available if the appropriate prerequisites are present. Instead, keep these layers in different directory trees and use individual link files for each. There is no limit to how many link files you use to add function to an Eclipse configuration.

Back to top

Making Eclipse (or any Eclipse-based product) work your way

You now know two things: The identified primary feature controls the world of product branding and preference defaults, and Eclipse sees contributions in the install directory or any linked Eclipse directory structure. This means you can make changes (with the associated risk, which just means be careful). These changes can enhance how you manage your Eclipse-based installation and make it support your rules for favorite preferences.

Using link files to manage an Eclipse install

You might want to consider a more managed environment instead of just dumping all the cool plug-ins (with referencing features I hope) into your Eclipse directory tree. If you need to update Eclipse, you really don't want to either unzip a new Eclipse on top or hunt through the list of features and plug-ins to find those you want to move forward.

Here is an approach for organizing your Eclipse or Eclipse-based product and builds on the capabilities of link files:

• Keep Eclipse or an Eclipse-based product clean. That is, don't add any of your features or plug-ins to the eclipse\features and eclipse\plugins directories.
• Create both an eclipse\links and eclipse\links-out directory in the existing Eclipse directory. If you are using an Eclipse-based product, the eclipse\links directory may already exist. The directory is not special, just a convenient place to hide link files when not in use.
• Create a one or more add-ons directories for the features and plug-ins you want to add to your configuration. In these directories, create an eclipse\features and eclipse\plugins directory structure.
• For each add-ons directory, create a link file in the eclipse\links-out directory. Copy those you currently want as part of your active configuration to the eclipse\links directory.

For example, assume you unzipped Eclipse into a directory named Eclipse-2.1.1, then created an add-ons directory named CoolTools, also in the Eclipse-2.1.1directory. In the CoolTools directory, you could have multiple directories, one for each tool or family of tools you want to add to Eclipse. Your structure might look something like Figure 3.

The EditorList.link file would contain either of these entries (not both):

path=D:/Eclipse-2.1.1/CoolTools/EditorList
path=D:\\Eclipse-2.1.1\\CoolTools\\EditorList

The slash is either one (/) or two (\\) depending on direction.

Be sure that the entry does not end with a space as this causes it to be ignored by Eclipse — it took me several hours to determine this the first time I used link files.

If you start Eclipse with a new workspace, all of Eclipse and the features and plug-ins found via link files will be available. If you were to add a link file and restart Eclipse using an existing workspace, the Configuration Changes dialog would be shown. If you remove a link file (as easy as moving it over to \links-out), the configuration change will be noted, but all you will see is a splash-flash.

You don't really have to move link files in and out to control the configuration; a better way is to just adjust the configuration using the Install/Update perspective. Of course, this assumes you have features for the plug-ins (see, another reason for features). Making configuration adjustments using Eclipse is discussed next.

Making configuration modifications using the Install/Update perspective

Root features and any feature defined as optional can be disabled in the current configuration. Once disabled, the features are still known to the platform; they are just not included in the current run-time configuration.

Previously, we discussed adding the Eclipse Examples to the active configuration. Once there, we can choose to disable them using the Install/Update perspective. If you were to open the Install/Update perspective for an Eclipse configuration that included the Eclipse Examples, you would see something like Figure 4.

By selecting the Disable Now button in the Preview view, you can temporarily remove the Eclipse Examples feature from the run-time configuration. When selected, Eclipse will prompt you to restart the Platform to process the configuration modification.

The Eclipse Examples feature will no longer be visible (or active) in the current configuration. To see the feature so that you can enable it again, you need to select the Show Disabled Features toggle in the Install Configuration view (see Figure 5).

This works for the Eclipse Example feature because it is a root feature. If you explore the other features in the Eclipse SDK, you will see that they do not include a Disable Now button in the Preview view. This is because they are defined as required.

If you are using the Eclipse SDK, you have the Platform, the JDT, and the PDE configured by default. If you do some plug-in development, but you don't need the PDE — or for that matter, you don't need the JDT all the time — you could disable these features if you made a small modification to Eclipse. Open the feature.xml file for the org.eclipse.platform.sdk.win32 feature and change these lines to include the optional="true" attribute:

                
<includes id="org.eclipse.platform.win32" version="2.1.1" match="equivalent"/> 
<includes id="org.eclipse.jdt" version="2.1.1" match="equivalent" optional="true"/> 
<includes id="org.eclipse.pde" version="2.1.0" match="equivalent" optional="true"/>
<includes id="org.eclipse.platform.win32.source" version="2.1.1" match="equivalent" 
   optional="true"/>
<includes id="org.eclipse.jdt.source" version="2.1.1" match="equivalent" optional="true"/>

You can now select these features in the Install Configuration view and disable them. If all of those defined optional above were disabled, the Platform still runs. And remember, you can always enable them again. Figure 6 shows the Install Configuration view showing which features are disabled.

These disable/enable decisions are local to the current workspace. You could have other workspaces active that include some or all of the disabled features.

This simple example should demonstrate the advantages of having features (they can be disabled) and the value of adding all possible features to your configuration using link files. You disable what you don't need for a given workspace and therefore optimize the current configuration.

Defining your own global preferences

Eclipse is good, but like any tool, it will not be perfect for you until you customize it a bit. Tools contribute preference pages that allow you to change the behavior or visual display of a tool. At last count there were 62 preference pages in Eclipse. Almost every time you visit a new one, you find an option you might like to change. But when you use more than one workspace, or work in a team environment where some options may have to be coordinated, this presents a challenge for how to best manage your choices across workspaces and with others.

Eclipse does offer an export/import option for preferences. On any page in the Preferences dialog, you can export preferences to an .epf file. This file can be imported when using another workspace or shared with others. You might even add it to a project shared with teammates so that everyone has access to the standard preference choices.

But this can get tedious, and if you forget, burdensome. There is another technique for defining global preferences that you should be aware of when using Eclipse or any Eclipse-based product. You can customize the default values for preferences by modifying the plugin_customization.ini file associated to the primary feature.

You find the primary feature by looking at the install.ini file in the eclipse directory. For example, the install.ini content in a standard Eclipse unzip looks like this:

                
# install.ini 
# java.io.Properties file (ISO 8859-1 with "\" escapes) 
# This file does not need to be translated.

# Required property "feature.default.id" contains the id of the primary feature 
# (the primary feature controls product branding, 
splash screens, and plug-in customization) 
feature.default.id=org.eclipse.platform

# Required property "feature.default.application" contains id of the core 
# application that gets control	on startup. For products with a UI, this 
# is always org.eclipse.ui.workbench; for "headless" 
products, this is product-specific.
feature.default.application=org.eclipse.ui.workbench

The feature.default.id=... entry identifies the default primary feature. Note that another feature could be declared as primary using the -feature option when starting Eclipse.

As with much of the feature control and branding process, the actual work is done in the plug-in associated with the feature. For Eclipse, this is the plug-in with the same id as the feature, the org.eclipse.platform plug-in. If you look in this plug-in, which is the branding plug-in for the primary feature, you will find a file named plugin_customization.ini. This file can contain entries similar to those found in an exported preference file. The file is read when Eclipse starts to identify any default preference values that should be used instead of those defined by the plug-ins themselves. This allows products, or you, to change plug-in behavior. The default plugin_customization.ini file contains only one entry:

                
# plugin_customization.ini 
# sets default values for plug-in-specific preferences 
# keys are qualified by	plug-in id 
# e.g.,	com.example.acmeplugin/myproperty=myvalue 
# java.io.Properties file (ISO 8859-1 with "\" escapes) 
# "%key" are externalized strings defined in plugin_customization.properties 
# This file does not need to be translated.

# Property "org.eclipse.ui/defaultPerspectiveId" controls the 
# perspective that the workbench opens initially
org.eclipse.ui/defaultPerspectiveId=org.eclipse.ui.resourcePerspective

This entry identifies the perspective that is opened for a new workspace or when you have shut down Eclipse after closing all perspectives. This entry might be different if you are using an Eclipse-based product.

The process of identifying which preferences you want to include requires a bit of hunting, but basically you should:

1. Start with a fresh workspace.
2. Modify a preference value you wish to change.
3. Export the preferences to an .epf file.
4. Inspect the file to identify new keys and determine if they map to the change you just made.
5. Copy one or more of the key entries to the plugin_customization.ini file in the branding plug-in (this is org.eclipse.platform when using Eclipse).
6. Test the result and either keep the new key or try again.

Note: If you are not comfortable with updating the product's plugin_customization.ini file, you can always create a copy of the file in another location and use a startup parameter that identifies the file when you start up Eclipse or an Eclipse-based product:

eclipse -plugincustomization myCustomDefaults.ini
            

Global preference examples

Example preference overrides are provided here as a demonstration of both the technique described above and suggestions for some values you may wish to include in your own customized plugin_customization.ini file.

We'll look at them in logical chunks based on goals I had for my customization.

• View tabs default to the bottom, but I like them at the top:
  

  # View tabs at the bottom org.eclipse.ui.workbench/VIEW_TAB_POSITION=128

  
  
  
• To not open the welcome pages for a new workspace and to stop the prompt when closing the workbench:
  

  # No welcome dialog at open and no confirm on close org.eclipse.ui.workbench/WELCOME_DIALOG=false org.eclipse.ui.workbench/EXIT_PROMPT_ON_CLOSE_LAST_WINDOW=false

  
  
  
• To disable the prompt or action to open a perspective known to the new project wizard:
  

  # Never change to perspective required by new project wizard (no prompt) org.eclipse.ui.workbench/SWITCH_PERSPECTIVE_ON_PROJECT_CREATION=never

  
  
  
• To define an alternate default text font:
  

  # Default text font (leaks into Java editor) # Note: you have to touch the font page and say OK/Apply (probable bug) org.eclipse.ui.workbench/org.eclipse.jface.textfont= 1|Lucida Console|9|1|WINDOWS|1|-15|0|0|0|700|0|0|0|0|3|2|1|49|Lucida Console;

  
  
  Note: The font preference entry is peculiar. It does not take affect immediately. If you visit the font page, the font defined above is shown, and will be used once you select OK or Apply. I was unable to get the key saved for the Java text font to work.
  
  
• To predefine an additional Java editor task tag:
  

  # Add to the default JDT task tags (TODO should probably be left) org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskTags=TODO,Edu-Sol

  
  
  
• To set the double-click default for the Package Explorer to be equivalent to the Go Into action:
  

  # Package Explorer GoInto on Double click org.eclipse.jdt.ui/packageview.doubleclick=packageview.gointo

  
  
  

Some customization is available even when the changes are not preference page-defined options. By glancing at the contents of an exported .epf after making my standard set of UI modifications, I noticed that some JDT decisions were stored as preferences.

• This preference key is used to tell the JDT UI that it does have preferences to read to change the default UI behavior:
  

  # Tells JDT it does have some prefs to use (forces a read of these values) org.eclipse.jdt.ui/CustomFiltersActionGroup.org.eclipse.jdt.ui.PackageExplorer. TAG_DUMMY_TO_TEST_EXISTENCE=storedViewPreferences

  
  
  Note: If the above key is missing, the next two sets of entries will not be processed.
  
  
• The active Package Explorer filters are stored as preference values:
  

  # Package Explorer filter - standard JDT defaults + library filter org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.LibraryFilter=true org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_.*=true org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.PackageDeclarationFilter=true org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_*$*.class=true org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui./ PackageExplorer.EmptyInnerPackageFilter=true

  
  
  
• The Outline view has a display option that reduces the tree depth when the view is showing content from an active JDT Java editor. The hover help Go Into Top Level Type is displayed for this toggle. This preferences entry controls this decision:

  # Outline view GoInto Toggle when using JDT editor org.eclipse.jdt.ui/GoIntoTopLevelTypeAction.isChecked=true

  
  
  

You may want to experiment a bit to find more preference keys that you want to identify new defaults for. Use the described process and check the results. You might want to do this with a temporary workspace. When you are satisfied, you can modify the plugin_customization.ini file for the active primary feature (just don't tell anyone I told you to do so!). Also note that you may find other keys that seem to be ignored, as I did, for the font that was to be used by the JDT. This entry, when placed in the plugin_customization.ini file, did not change the preference page at all.

Back to top

Summary

Features are the unsung hero of Eclipse — they are important because they are the unit of Eclipse configuration management, they support product branding, and they are part of how products build customized solutions on top of the Eclipse Platform. Using features you can:

• Identify, based on feature branding, who provided the different functions that are available when you are working with an Eclipse-based product
• Build on product branding capabilities to further customize Eclipse
• Automate tasks in the plug-in development environment
• Dynamically change the configuration for a given workspace by managing the enabled/disabled state of root features, or features included by another but defined as optional, using the Install/Update perspective

So, give features a go, if only to automate some of the plug-in build processing, or to make your own Eclipse environment better by using the customization install/link file structuring approaches covered here.

Back to top

Download

Information about download methods

Resources

Learn

• The Eclipse.org article "PDE Does Plug-ins" offers an alternative description of how to use the PDE to build plug-ins.
  
  
• Download the plugin_ customization.ini file described in this article.
  
  
• The Java Developer's Guide to Eclipse, by Sherry Shavor, Jim D'Anjou, Dan Kehn, Scott Fairbrother, John Kellerman, and Pat McCarthy (Addison Wesley Professional, 2003). In particular, see Chapter 22 on developing features, and Chapter 34, Exercise 7, on feature development and deployment.
  
  
• Additional detail on branding is on Eclipse.org in the development resources for the Update Manager sub-project.
  
  
• "Developing Eclipse plug-ins" walks though a simple "Hello, World" plug-in creation.
  
  
• "Extend Eclipse's Java Development Tools" walks though the process of creating Eclipse plug-ins using the PDE.
  
  
• Check out the "Recommended Eclipse reading list."
  
  
• Browse all the Eclipse content on developerWorks.
  
  
• New to Eclipse? Read the developerWorks article "Get started with Eclipse Platform" to learn its origin and architecture, and how to extend Eclipse with plug-ins.
  
  
• Expand your Eclipse skills by checking out IBM developerWorks' Eclipse project resources.
  
  
• To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.
  
  
• For an introduction to the Eclipse platform, see "Getting started with the Eclipse Platform."
  
  
• Stay current with developerWorks' Technical events and webcasts.
  
  
• Watch and learn about IBM and open source technologies and product functions with the no-cost developerWorks On demand demos.
  
  
• Check out upcoming conferences, trade shows, webcasts, and other Events around the world that are of interest to IBM open source developers.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

Get products and technologies

• Download Eclipse Platform and other projects from the Eclipse Foundation.
  
  
• Download IBM product evaluation versions, and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
  
  
• The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Features package plug-ins
• Primary feature brands the product (but you have control)
• Features build plug-ins (if you let them)
• Platform configuration management
• Feature branding identifies your contributions at run time
• Strategies for building features using the PDE
• Structuring features
• Making Eclipse (or any Eclipse-based product) work your way
• Summary
• Download
• Resources
• About the author
• Comments

Dig deeper into Open source on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers