You can activate the Plug-in Spy by pressing Alt+Shift+F1 in the Eclipse IDE. It gives you information about the currently selected user interface component. This way you can get immediate access to the plug-in which is currently running.

Click on any of the linked elements to obtain more information about that element. For example, if you click on the contributing plug-in the tool opens the manifest editor for this plug-in.

Press Alt+Shift+F2 and select a menu entry or click a toolbar entry to see information about this element.

SWT Spy for Eclipse is a tool that prints out information about the widget under the cursor. Currently, this includes style, layout and parent information. See SWT Development Tools homepage for more information.

The Java Development Tools (JDT) of the Eclipse IDE limit the scope of search related activities. By default, JDT considers elements from opened projects including their dependencies as well as elements from the standard Java library.

For example, the Ctrl+Shift+T (Open Type) shortcut will not find the ISources interface if it is not referred to in the current workspace. As plug-in developer you want to have access to all classes in your current target platform.

The target platform is the set of plug-ins against you develop. By default, the plug-ins from the Eclipse IDE installation are used as target platform.

You can include all classes from the current target platform to be relevant for the Eclipse Java tools via the following setting: Window → Preferences → Plug-in Development → Include all plug-ins from target in Java search.

Use the Ctrl+Shift+A shortcut to search for an extension point. Definition and usage of an extension point have different icons. For example, to see which plug-in defines the org.eclipse.menu.ui extension point, enter it in the dialog and select the entry with the blue icon.

Plug-in Search allows you to perform a detailed search for extension points. Select the Search → Search → Plug-in Search menu. You can specify what your are searching for as demonstrated in the following screenshot.

In case you have imported the source code of an Eclipse project into your workspace you can also use the plain text search. Select the Search → Search menu entry and switch to the File Search tab.

As indicated in the following screenshot you can search for a text, use regular expressions and restrict which files to search by specifying a file name pattern. This is a very flexible way to search and allows you to find almost everything.

Eclipse provides a tracing facility that is turned off by default but can be turned on at runtime. If turned on, the Eclipse IDE writes additional information to a specified log file.

To turn tracing on, you need to create a trace-options file that contains a list of the debug options that you want to turn on.

By default, this file is called .options and the Eclipse runtime looks for such a file in the Eclipse install directory. The text should contain one key=value pair per line. To turn on the trace options in the preceding two examples, you need an options file that looks like this:

# turn on debugging for the org.eclipse.core.resources plugin.
org.eclipse.core.resources/debug=true

# monitor builders and gather time statistics etc.
org.eclipse.core.resources/perf/builders=10000

# monitor resource change listeners and gather time statistics etc.
org.eclipse.core.resources/perf/listeners=500

# monitor workspace snapshot and gather time statistics etc.
org.eclipse.core.resources/perf/snapshot=1000

# monitor workspace snapshot and gather time statistics etc.
org.eclipse.core.resources/perf/save.participants=500

# debug build failure cases such as failure to retrieve deltas.
org.eclipse.core.resources/build/failure=true

# reports the cause of autobuild interruption
org.eclipse.core.resources/build/interrupt=true

# reports the start and end of all builder invocations
org.eclipse.core.resources/build/invoking=true

# reports the start and end of build delta calculations
org.eclipse.core.resources/build/delta=true

# for incremental builds, displays which builder is being run
# and because of changes in which project.
org.eclipse.core.resources/build/needbuild=true

# prints a stack trace every time an operation finishes that requires a 
build
org.eclipse.core.resources/build/needbuildstack=true

# prints a stack trace every time a build API method is called
org.eclipse.core.resources/build/stacktrace=false

# report debug of workspace auto-refresh
org.eclipse.core.resources/refresh=true 

You can use the corresponding preference dialog to find the values you want to enable. See Section 7.3, “Turning on tracing at runtime”.

Finally, you need to enable the tracing mechanism by starting Eclipse with the -debug command line argument. You can optionally specify the location of the debug options file as either a URL or a file-system path after the -debug argument.

It is also possible to turn on some tracing options at runtime via the Eclipse IDE preferences as depicted in the following screenshot.

If you want to modify standard Eclipse plug-ins, you can use Feature Patch Projects. A Feature Patch Project can contain plug-ins which replace existing plug-ins. This would allow you to create an update site for this feature and users can use your version of the modified code.

Each feature can only be patched once.

A feature project can get created via File → New → Other... → Plug-in Development → Feature Patch.

In this dialog select the feature which you want to patch. Add every modified plug-in to your new Feature Patch Project and export it as a p2 update site.

Please consider a contribution if this article helped you. It will help to maintain our content and our Open Source activities.

Writing and updating these tutorials is a lot of work. If this free community service was helpful, you can support the cause by giving a tip as well as reporting typos and factual errors.

If you find errors in this tutorial, please notify me (see the top of the page). Please note that due to the high volume of feedback I receive, I cannot answer questions to your implementation. Ensure you have read the vogella FAQ as I don't respond to questions already answered there.

This tutorial is Open Content under the CC BY-NC-SA 3.0 DE license. Source code in this tutorial is distributed under the Eclipse Public License. See the vogella License page for details on the terms of reuse.

Source Code of Examples