Home
.. Links
.. Search
.. Plugins
.. Help
.. Irc Faq

Projects
.. Platform/Faq
.. JDT/Faq/Plan
.. PDE/Faq
.. SWT/Faq
.. RCP/Faq

Tools Projects
.. CDT/Faq
.. GEF/Faq
.. EMF/Faq

Wiki Tutorials

Hosted Projects
.. MTJ
.. Google Summer Of Code 2007
.. Update Manager 2.0
.. EasyEclipse
.. Stylebase for Eclipse

Archives

PDE Dynamic Classpath

How do I create a perspective without an editor?

When I export plugin, not all the necessary files are exported.

When computing classpath the "src" folder is reset to "/". How do I fix this?

How do I add a third-party JAR to a plugin classpath?

3rd party jar summary:

Option 1: turn the jars into plugins
Use New>Project>Plug-in Development>Plug-in from existing JAR archive. That will turn one or more jar files into a single jar plugin. For something like log4j you can then set up Buddy-Classloading, etc.

Option 2: include the jars in a plugin
1. Use Import>File System to import the jar files into your plugin project, say in the <project>/lib directory.
2. Use "Add..." to add the jars to the classpath section of the manifest>Runtime tab.
3. Use "New..." to add "." library back (with no quotes, of course).
4. Make sure your binary build exports the new jar files on the manifest>Build tab.
5. Save
6. On the project, use popup menu>PDE Tools>Update Classpath to correctly add the jars to the eclipse project classpath.
7. Then you can go back to the build path>Runtime tab and export all of the packages you would like another plugin to be able to see.

Check out https://bugs.eclipse.org/bugs/show_bug.cgi?id=108781

How to Write rule for syntax highlighting?

What products (other than Eclipse) will my Eclipse plugins work in?

Where is the Javadoc for Eclipse API?

Where is the source code for Eclipse?

How come I get ClassNotFoundExceptions when running my plugin, even though it all compiled?

How can I add extra classes to the classpath at runtime?

How can I add resources in my workspace to the classpath of a plugin at runtime?

Plugin "org.eclipse.core.boot" is missing. What do I do?

How come my plugin that uses Xerces doesn't run?

<require>
  <import plugin="org.apache.xerces"/>
</require>

How do I get code that calls getContextClassLoader() to load my plugin class?

Thread cur = Thread.currentThread();
ClassLoader save = cur.getContextClassLoader();
cur.setContextClassLoader(getClass().getClassLoader());
try {
  // do whatever needs the contextClassLoader
} finally {
  cur.setContextClassLoader(save);
}

How to programmatically find the plugin instance?

The most common pattern for doing this is to have a static method on your plugin class that returns the instance. Here's an example:

public class MyPlugin extends Plugin {
private static MyPlugin plugin;
public MyPlugin(IPluginDescriptor pluginDescriptor) {
super(pluginDescriptor);
plugin = this;
}
public static MyPlugin getPlugin() {
return plugin;
}
}

This works only, if the constructor of the plugin class is called, of course. Before Eclipse 3.0 this was usually the case. In Eclipse 3.0 though it is necessary to include "Eclipse-AutoStart: true" in your MANIFEST.MF file. Further details can be found in FAQ 101 of the "Oficial Eclipse 3.0 FAQ".

How do I print to the console from my plugin?

How can I get an IFile from an absolute path?

How can I get an IFile for a file outside the workspace?

An action creates/modifies lots of files. How do I get Eclipse to update/build only once?

Why don't my markers show up in the margin of my editor?

How can I get my plugin to start when Eclipse starts up?

How to implement the update mecanism?

 Does anybody can help me for updating a plugin with a defined URL, How
 work the archive element in site.xml, how does it work with
 features.xml ? 
 My site.xml:

 Thx,
 -Emmanuel

How do I parse a Java class in my plugin?

Why does Update Classpath cause thousands of compile errors?

What is this "platform" protocol from plugin getInstallURL?

Why doesn't setting the isDirty() flag work?

Finding the package containing an Eclipse class

The problem...

The solution...

findpkg <some-class-in-package>

#!/usr/bin/perl
use warnings;
use strict;

#---BEGIN CONFIG---
my $eclipsedir = 'eclipse2';
#---END CONFIG-----

my $tofind = $ARGV[0];

my @progress = qw( | / -  );
my $progress = 0;
sub printProgress {
  print "$progress[$progress]
";
  ++$progress;
  $progress = 0 if ($progress > $#progress);
}

print "Searching for $tofind
";
chdir "$eclipsedir/plugins" or die "Couldn't chdir to $eclipsedir/plugins: $!
";

printProgress;
my @files = `find . | grep jar$`;
printProgress;

foreach (@files) { 
  my @list = `jar -tf $_`; 
  printProgress;
  foreach (@list) { 
    print "
$_" if ($_ =~ $tofind);
  }
}

print " 
";

How do I find out the directory where my plug-in is installed by program?

The plugin installation directory should not be used to write files to
It's better to use YourPlugin.getDefault().getStateLocation()

If you have very good reasons, you can find the installation directory as
follows:
final URL url = Platform.find(Platform.getBundle(YourPlugin.PLUGIN_ID),new
Path("/"));

How to find which editor is working on a specific file?

How Finding Projects And Resources

How to get the selected project?

You need to open the build.properties file.
In there update the bin.includes setting. You need to add all non-source and non-runtime jar files and/or directories that should be exported.
If not in bin.incluse it won't be exported. For further build.properties info see the Eclipse Help Contents->PDE Guide->Deploying a plugin->Deploying a feature->Build configuration.
I executed Compute Path from the plugin editor and it always resets the location of my source folder from "src" to "", so that I need to set it manually again.
How do I fix this?

1) open the PDE manifest editor on your plugin.xml file

2) switch to the 'Runtime' page

3) make sure that a runtime library is defined. If not, add one

4) select the library

5) press the 'Add' button next to the 'Library Content' pane

6) select your source folderNote that this information is stored in the build.properties file, not the plugin.xml file.

If you're asking how you can add a JAR in some arbitrary location on the user's system, you can't. A plugin can only refer to JARs in itself or another plugin. Both are set up in plugin.xml. For example,Adds the JAR files myplugin.jar (where is the name of your plugin), thirdparty.jar (where is...whatever it is) and the JAR files in the plugin org.apache.xerces to your plugin's classpath at runtime. In PDE, if you setup the dependencies as shown above and save plugin.xml, the JARs will automatically be added to your project's build path, as well.Also, if you want this third-party jar to be exported when you do a plugin build using PDE, then update your build.properties files and add the jar to the bin.includes setting. That way it knows to copy that file too.Note: if you are doing a copy into plugin using the build.properties, make sure you have a license to copy the third-party jar for redistribution.Of course, you can't answer this without testing, but here is the general idea. Plugins developed for Eclipse 1.0 may also work in the current version of IBM's Websphere Suite Application Developer (WSAD). Plugins developed for Eclipse 2.0 will run in a future version of WSAD. In addition, plugins may work in other products based on Eclipse, if they include the plugins your plugin depends upon. Judging from the list of Eclipse sponsors, eventually this could be a rather large number of products. [List others here]In EclipseHelp -> Help ContentsThen navigate to:Platform Plug-in Developer GuideReferenceAPI Reference-here under each group you can find the java doc for that build(i.e. it is generated as part of the build process right out of the current java files) [Thanks to Veronika Irvine]Assuming you downloaded the SDK, it's in various plugin folders in files matching the pattern *src.zip. The source for a plugin is not necessarily in the same folder as the plugin. A program that will extract the source from the various zip files into a local folder is . This will also optionally build Javadoc for all classes, including internal classes which are not included in the Javadoc shipped with Eclipse.The build path, java classpath variable and any other classpath you might have defined are irrelevant at runtime. At runtime, the "classpath" is computed on a per-plugin basis. For a given plugin, the runtime classpath includes only the following:1) All JARs and directories specified in "library" elements of your plugin.xml file. These JARs and directories must be within your plugin's install directory (the directory with the same name as your plugin ID).2) Any directories in your plugin defined by the "-dev" command line parameter. For example, if "-dev bin" is supplied on the eclipse command line, all "bin" directories will be included on the classpath of their respective plugin. This is used during development, so you don't have to JAR up your code every time you run your test workspace.3) Everything on the bootclasspath when Eclipse was launched4) The JAR file from the org.eclipse.core.runtime plugin.5) The exported library entries of all plugins that your plugin is dependent on (all "requires" elements in plugin.xml). This is recursive, so you have access to the exported libraries of all dependencies of your dependencies, etc.Basically, this means that ALL code must either belong to some plugin, or be on the boot classpath. A common technique for using external libraries is to wrap them in a simple plugin and include this plugin in the "requires" section for your plugin. See for example how the org.apache.xerces plugin is merely a wrapper for a third party library.You can't. You can however create a new class loader that includes whatever JARs you want. See how this is done in the ant plugin (org.eclipse.ant.core). The ant plugin creates a new class loader (AntClassLoader), that includes all JARs from the ant classpath preference page. If you parent this new classloader to the classloader for your plugin, code in those JARs will be able to reference code in your plug-in.That is a dangerous thing to do. First is that you are loading user code into the IDE jvm. If it has bad errors or even calls System.exit() it could cause your IDE to go down or have severe problems. Second, since each project could have a different level of jvm from what the IDE is using you can't necessarily load them in. Third, unless you use your own classloader, any classes loaded will be seen by the entire IDE and only one version of the class can be loaded, if the class is changed the new version wouldn't be loaded. Fourth, it may difficult to get rid of the instances. Sometimes things you aren't aware of hold on to instances of classes and so they won't be GC'd.In most cases you can get the analysis you need out of the JDT and AST model, which does a pretty good job of looking at the classes.But to answer the question directly, you must provide your own class loader which loads, e.g., from the output directory. If you have loaded a class in this way and want to reload a new version, you will have to discard the class loader and create a new one. Be careful not to keep references to class loaders, user classes or instances, or old versions will pile up in memory. You take responsibility for any instability that may result. If you ask for help, you're quite likely to get a lecture, instead. On the other hand, if you go the JDT and AST route, you'll find lots of people eager to help you learn how.Look under Preferences->Plugin Development->Target Platform.This shows a list of the external plugins (not in your workspace) that should be used when launching a runtime workbench. You should typically "Select All" in this list. Alternatively, you can check off the external plugins on the "Plugins and Fragments" page of the launch configuration dialog. Preferences set the default for new launch configurations but don't change existing ones; the launch configuration dialog changes existing configurations. If you have seen this error, you probably want to do both.The launch configuration dialog is reached by Run / Run... (or Debug...). Select the configuration that failed. In the Plugins and Fragments tab, click the "Choose plugins and fragments to launch from the list" radio button to make sure it is doing what you want. Check the External Plugins box.If you get an exception like org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found (others are possible) you have a conflict with the version of Xerces used by one of the Eclipse plugins you depend on. The simplest way to fix this is to remove the Xerces jar or jars from your plugin and add the following to your plugin.xml.If you stick with your own version, you'll have to play . There is no way to set up plugin versions or dependencies that will automatically fix this problem.Read the next answer, too, as it deals with the most common problem with plugins using Xerces.Several libraries (bean persistence, Xerces) call getContextClassLoader() on the calling thread when attempting to dynamically load classes. The context class loader in, e.g., the event thread, is not set by default to the class loader for your plugin classes, but you can set it by calling Thread.currentThread().setContextClassLoader(getClass().getClassLoader()) before calling the library. To keep it clean, you should follow this pattern:The console is used to display the output of user programs. Plugins may not write to it.If you need to record error information, you should use the .log file (MyPlugin.getPlugin().getLog()). PDE provides an "Error Log" view for displaying this output from within the environment.If you simply want to print out information to help you debug your plugin, you can use System.out.println. If you start Eclipse with java instead of javaw, these lines will be printed to the console which started Eclipse.If your plugin needs to display some sort of console-like output to the user, then you'll probably need to write your own view for this.* With Eclipse 3.0 and above, the console classes in org.eclipse.ui.console can be used to the same effect, you can redirect the output stream of your plugin to the Console view.IF there is a corresponding IFile in the workspace, it can be found using:ResourcesPlugin.getWorkspace().getRoot().getFileForLocation(fileSystemPath);You can't. If you must have an IFile, it must be imported into the workspace. When an object becomes an IResource it acquires certain properties, such as change notification, auto-building, and marker storage, which cannot be supported without adding the resource to the workspace using the Core API.The IStorage interface was created for situations where there is a need to manipulate some content without creating a real IFile. Since IFile extends IStorage, you can develop an interface that accepts files both inside and outside the workspace.This is a very important concept that is the source of a lot of performance problems in plugin code. If you're modifying the workspace many times, you should wrap all the code in an IWorkspaceRunnable, and pass it to IWorkspace.run(...). This will batch all the changes, and ensure there is only one build/update phase at the very end.If you're operating at the UI level, it's also typical to wrap your code in an IRunnableWithProgress so that the work can be performed in a non-UI thread. To save you from having to wrap your code in two different kinds of runnables, the UI provides WorkspaceModifyOperation and WorkspaceModifyDelegatingOperation so that you only have to wrap your code once.See org.eclipse.ui.texteditor.MarkerUtilities.There is an extension point, org.eclipse.ui.startup, which allows plugins to register for early activation. These plugins must provide a class that implements the org.eclipse.ui.IStartup interface. The [Workbench->Startup] preference page allows users to deactivate early startup participants if they don't want them running.Plugin writers should be aware that in most cases loading on startup is unnecessary. In particular, making your feature appear to initialize faster by pre-initializing during startup makes Eclipse look bad so you can look good. In any case, the user can disable startup loading, so plugins should have a fallback strategy in case that happens.<?xml version="1.0" encoding="ISO-8859-1" ?> &ltsite>&ltdescription&gtdesc</description> &ltfeature url="features/my_feature_0.1.jar">&ltcategory name="name" /> </feature>&ltarchive url="???" path="???" /> &ltcategory-def name="name" label="label" /> </site>Emmanuel, feature.xml only contain the name of the plugin and its versionSite.xml can make the mapping between plugins/_.jar and a URLoff the top of my head (and even if I develop it) I believe the url can be relative or absoluteso for a plugin version 1.0.0 you will have< archive path="com.company_1.0.0.jar" url="http://myserver:8081/mypath/com.company.jar >Feature url can be absolutecheck < http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update-home/doc/eclipse_update_packaging.html >I checked and we missed the example in the spec, sorry about that...Christophe ElekEclipse Projecthttp://www.eclipse.orgPlease see Because it removes all your Java Build Path dependencies, forcing you to re-add them by hand.But you probably want to know how to make it stop that. The answer, courtesy of Harald Niesche, who tirelessly ran this down while the rest of us just whined, is in Window > Preferences > Plug-in Development > Target Platform.If you see all the boxes there unchecked, then Update Classpath misbehaves as above. If, however, you click the Not In Workspace button - which checks every box except your own plugins - and click Ok, Update Classpath will be your puppy. It will use your plugin.xml to figure out your build dependencies, fix up their paths using the appropriate system variables, do the same for source references, etc. Good puppy. [Bob Foster]An example is: "platform:/plugin/my.plugin_1.0.0"If you look closely at the URL returned, it is a special protocol"platform:", not a file system url. You need to callPlatform.resolve(URL) to get the final actual URL. The reason there isthe platform protocol is so that you can create an installationindependent URL to a plugin install directory. That way you don't haveto worry about the installation structure. But there are two things tobe aware of:1) The final resolved URL may not necessarily be a "file:" protocol,i.e. it may not be on the same system. There are ways of running wherethe plugins are on a different system.2) There is not just ONE plugin directory. Plugin installs may be spread acrossmore than one directory (each individual plugin will be fully containedin one directory, but not all plugins will be in the same plugindirectory). Because of this, you can't make the assumption that since youhave the install directory of one plugin, then all of your plugins arein that same directory.You must tell the Eclipse platform that you have changed the value being returned by isDirty(). You do this by firing a propery change event, which will prompt Eclipse to requery the isDirty() method of your editor and take appropriate action (such as adding/removing the asterisk and enabling/disabling save). To do this, simply add the line "firePropertyChange(PROP_DIRTY);" from inside your Editor. Probably the easiest way to do this is to write a setDirty() method that handles this for you.You're busy hacking up your next kewl plugin for Eclipse and decide you want to reuse some nice Eclipse code you found during your code spelunking sessions. But there's only one problem: This nice code includes a class in some package you haven't put on your build path and you haven't a clue as to what package to include. So how do you find it?If you're either running Linux or happen to have the Cygwin tools installed on Windoze, here's a "findpkg" Perl script you can drop somewhere in your path that will do just what you need. In order to find the package containing that class you need, just type:(Notice that you have to change one config line at the top of the following script. It also assumes that the JDK tools are in the path.)

Comments:

From pravinsinh - 8/31/05 1:36 AM

From igorcov - 6/24/05 3:26 AM

From sunqh [211.157.248.31] - 8/16/04 8:31 PM

From sunqh [211.157.248.31] - 8/16/04 8:22 PM