|Gathering Information About Your Plug-in|
|Why doesn't my plug-in work? (Debugging your plug-in in the Eclipse SDK)
Sometimes plug-in developers write their plug-ins and test them in the Eclipse environment and everything works fine. But then they export their plug-in and try to run it in an Eclipse build and its not there. Here are a few debugging tips for plug-in developers to help them figure out what is going on within the Eclipse system. These tips are also handy when supplying Eclipse plug-in developers information in bug reports when you are trying to help them track down problems.
Note that this document was written with a win32 system in mind but most items can be applied to other platforms.
|Where is my Log?
Eclipse has a log file where problems are recorded and usually this is the first thing that an Eclipse developer asks for when you report a problem. The log file can be found in a couple of places:
|Know your VM
When you double-click on the Eclipse icon, the Eclipse executable searches your path and runs the first Java executable that it finds. This can be problematic people aren't always aware of what they have installed. Sometimes multiple Java VMs may be on your path but an older version may appear first so that is the one that is being used to run Eclipse. Its always best to explicitly run with a known vm using the -vm command line argument and specifying the path to the executable.
|Use a console
When you double-click on the Eclipse icon to start Eclipse, by default it runs
If you are running with a console, then you are able to ask the VM for a stack
dump of the threads that are currently running. In the console, hit
Above when we said "console" we meant DOS console but just so they
don't feel left out OSGi has a console too! And it can provide you with lots
of useful information. Start Eclipse with the -console command line argument
to start the OSGi console. The "
|Don't Miss Log Entries
Generally in Eclipse when you get an error, a message and stack trace is logged
to your workspace log. This is great but can easily be missed unless you are
looking for it. And some plug-ins silently log entries to the log file. Tsk
tsk. In order to never miss entries being logged, we use the
Most plug-ins take advantage of the debug options file mechanism that the runtime provides. This means that you can provide a file with a list of key/value pairs of debug options and the appropriate plug-ins will recognize this and print out their debug information.
Most plug-ins which use this mechanism provide a default
With the -debug command line argument you can optionally specify the location
of the debug options file to use. If you don't specify one, then it is assumed
that the file is named
Even if you use
Note that all debug information is displayed to the console and not to a log file.
|Cleaning My Configuration
If you are having problems getting the system to pick up your new plug-in,
then perhaps your configuration is out of date. This might be the case if you
just unzipped a new plug-in into your
There are other optional arguments that can be passed along to the VM and these must be put at the end of the command-line. Common arguments to pass are the maximum VM heap size and values for System properties.
|Putting it all together
That's a lot of information and command-line arguments. Here is an example where it is all put together.