If you want to help out with plugin packaging, read this guide. If you're just a plugin developer, scan through this document to have an idea of how to make the packager's job easier.

Read the build requirements

Compile the source yourself

Check plugin properties

Ensure that the version number listed in the plugin properties file is identical to the version number in the release announcement. This will prevent problems such as the plugin manager thinking there is a new version of the plugin out when there actually isn't.

Make sure that the dependencies look reasonable. There are only 2 versions of jedit supported, 4.2final and 4.3preX. Make sure the proper version of jedit is listed.

All plugins should use the jEdit 4.3 API. If a plugin is submitted that uses an older iteration of the jEdit plugin API, consult with the author, and pressure them to use the new API. If the jEdit 4.3 API is being used, the activate property of the plugin should be set to defer. If it has another value, consult with the plugin author, and ask them to change the property unless there is a compelling reason it should be set to something else.

Make sure all external dependencies are specified accurately, and make sure that any library JARs bundled with the plugin are listed in the jars property.

Make sure that no other plugin bundles library JARs provided by this plugin. If another plugin bundles them, either the JARs should be moved to a common plugin (like CommonControls or JakartaCommons), or the other plugin should become a dependency of this one.

Check the plugin GUI

The plugin should not make any changes to jEdit's GUI after install. This includes showing "setup wizards" on startup, docking windows by default, or providing default keyboard shortcuts. These changes should either be removed from the properties file, or the release of the plugin postponed until the author removes these changes.

The plugin should provide a clearly-organized submenu in the Plugins menu, complete with menu items for all dockable windows. Not everybody uses the Docking option pane, and not everybody docks all their windows! If a user chooses to use a window in floating mode, and the plugin developer does not provide menu items, there is no way to access the window.

Online help is not a strict requirement -- some plugins are so simple it is redundant -- but any non-trivial plugin should have online help. Make sure the HTML renders well in jEdit's help viewer.

Review the plugin code

A full code review is certainly not required and would make plugin packaging too time-consuming. However, a quick "sanity check" scan through the source is a good idea. In particular, look for these issues in the plugin core class:

• Initializing resources in start(), and not cleaning up in stop(). This is a sign of the plugin not being properly updated for the jEdit 4.2 API.
• Assuming that no buffers or views are open yet in start(), but taking action on open buffers/views in handleMessage(). Again, this is a holdover from the jEdit 4.1 days that is no longer valid.
• Duplication of features found in other plugins. They should either be removed, or the other plugin should become a dependency of this one, and its code reused and extended.

A few general issues to look for in other source files:

• Assuming jEdit.getSettingsDirectory() is non-null. As specified in the Javadoc, this may be null if jEdit was run with the -nosettings switch.
• Hardcoding a settings directory of ~/.jedit.

Packaging and Uploading

This is actually quite an involved process. There are some Python scripts, known as "pjo", and accompanying documentation, which describes the process of packaging and uploading step-by-step.

Anyone who packages plugins and has ideas on how to improve these scripts is welcome to discuss and contribute improvements to this script on jedit-devel. They can be checked out as a separate project in the plugins repository.