There are some Python scripts, known as "pjo", and accompanying documentation, which describes the process of packaging and uploading step-by-step.Īnyone 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. This is actually quite an involved process. Hardcoding a settings directory of ~/.jedit.As specified in the Javadoc, this may be null if jEdit was run with the -nosettings switch. Assuming jEdit.getSettingsDirectory() is non-null.They should either be removed, or the other plugin should become a dependency of this one, and its code reused and extended.Ī few general issues to look for in other source files: Duplication of features found in other plugins.Again, this is a holdover from the jEdit 4.1 days that is no longer valid. Assuming that no buffers or views are open yet in start(), but taking action on open buffers/views in handleMessage(). This is a sign of the plugin not being properly updated for the jEdit 4.2 API. In particular, look for these issues in the plugin core class:Īnd not cleaning up in stop(). However, a quick "sanity check" scan through the source is a good idea. Make sure the HTML renders well in jEdit's help viewer.Ī full code review is certainly not required and would make plugin packaging too time-consuming. Online help is not a strict requirement - some plugins are so simple it is redundant - but any non-trivial plugin should have online help. 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. The plugin should provide a clearly-organized submenu in the Plugins menu, complete with menu items for all dockable windows. These changes should either be removed from the properties file, or the release of the plugin postponed until the author removes these changes. This includes showing "setup wizards" on startup, docking windows by default, or providing default keyboard shortcuts. The plugin should not make any changes to jEdit's GUI after install. 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. Make sure that no other plugin bundles library JARs provided by this plugin. 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. 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. If the jEdit 4.3 API is being used, the activate property of the plugin should be set to defer. 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. Make sure the proper version of jedit is listed.Īll plugins should use the jEdit 4.3 API. There are only 2 versions of jedit supported, 4.2final and 4.3preX. Make sure that the dependencies look reasonable. Such as the plugin manager thinking there is a new version of the plugin out when there actually isn't. To the version number in the release announcement. Compile everything yourself.Įnsure that the version number listed in the plugin properties file is identical It is essential that the layout of the packaged plugin archive follows the build requirements.ĭo not package binaries provided by the plugin developers. If you're just a plugin developer, scan through this document to have an idea of how to make the packager's job easier. If you want to help out with plugin packaging, read this guide.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |