PreviousNextTracker indexSee it online !

(114/231) 3276647 - NPE if uninstalling plugin that packages non-jar files

I'm working on creating a small plugin that extends Templates (or potentially SuperAbbrevs) that simply provides a number of useful pre-defined templates, in particular ones that help with plugin development, e.g. a template for services.xml, build.xml, etc.

In order to extend Templates, this plugin would simply need to extract the template files to ${SETTINGS}/templates, and either tell the user to restart jEdit or tell Templates to refresh. In order to prevent unnecessary future clutter, I would like to be able to have jEdit remove the extracted templates when the plugin is uninstalled.

I've run into a bug (in 4.3.2, correct me if it's been fixed since) that makes doing this kind of thing impossible. The documentation says to use the plugin.className.files property to define non-java bundled files, but when uninstalling the plugin the activity log prints a NPE:

4:13:01 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: java.lang.NullPointerException
4:13:01 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at org.gjt.sp.jedit.PluginJAR.transitiveClosure(
4:13:01 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at org.gjt.sp.jedit.pluginmgr.ManagePanel$RemoveButton.actionPerformed(

For flexibility, I'm setting the plugin.className.files property dynamically in the plugin's start method relative to the jar directory, e.g. ../templates/services.xml. When the plugin manager prompts "are you sure you want to remove the following plugins", it displays the correct path of the jar and each of the extracted files, but then fails on the NPE because it thinks the template files are plugins.

On a related note, I think the process of creating a plugin that distributes files through the settings folder is overly complicated. The EditPlugin class contains several convenience methods for retrieving files from the plugin's home directory, but none to extract files from the plugin jar beyond IOUtilities, which still requires you to explicitly define input/output streams for each file. I think there should be an additional plugin property (like 'resources') that would tell the plugin to automatically extract the listed files/folders to the plugin's home. And then I think the files property should kill two birds with one stone; 'jars' should be used for anything in jars/, and so 'files' could specify plugin resources in a way that mirrors the settings folder, so that specifying '/templates/services.xml' as a file would automatically extract it to ${SETTINGS}/templates/services.xml, and then remove it when the plugin is removed.

Congratulations to anyone who successfully made it through that wall of text. =)

Submitted kog13 - 2011-04-05 - 21:45:12z Assigned nobody
Priority 5 Category plugin manager
Status Open Group None
Resolution None Visibility No


2012-08-14 - 14:35:42z
This is partially fixed by bug
Your problem was only when removing the plugin if yes, it is completely fixed but I'm not sure about using resources like this.
Do you have an example of your Templates plugin so I can test ?