JBoss-IDE Coding Conventions

Plugin

Naming

Plugin project name should begin with org.jboss.ide.eclipse.

'Example' : org.jboss.ide.eclipse.xdoclet.core for the plugin related to the core functionalities of Xdoclet.

Plugin main class should be named according to the plugin. The last(es) fragment are used for that.

'Example' : If the plugin is named org.jboss.ide.eclipse.xdoclet.core the plugin class will be org.jboss.ide.eclipse.xdoclet.core.XdocletCorePlugin.

Plugin main class should inherit from org.jboss.ide.eclipse.core.AbstractPlugin. This plugin acts as a base for all the plugins in JBoss IDE. It contains redundant code used by plugins. To do this, the org.jboss.ide.eclipse.core plugin is needed as a dependency.

Two entries are mandatory in a file call plugin.properties :

plugin.name=JBoss Core Plugin plugin.provider=JBoss Team

They are used in the plugin descriptor plugin.xml.

For the generated jar of the plugin, the jar is named like the plugin but dot are replaced with dash.

'Example' : The plugin org.jboss.ide.eclipse.xdoclet.core has a generated jar called org-jboss-ide-eclipse-xdoclet-core.jar.

Structure

The default structure for a plugin is :

• doc/ (if doc is provided)

• icons/ (if icons are provided)

• lib/ (additionnal libraries used)

• libsrc/ (additionnal libraries source code)

• resources/ (for non UI resources)

• src/ (Java classes and Resource Bundle)

• build.properties

• build.xml

• license.html (the license terms)

• plugin.properties

• plugin.xml

I18N

Each plugin should use the localized strings.

For the localized strings in the code, Eclipse has a nice tool to generate a Class and a Properties file. For the class, the naming follows the plugin name

Example : the XDocletCorePlugin will have a I18N class named XDocletCoreMessages and a property file named XDocletCoreMessages.properties in the same package as the plugin class.

For the localized strings in the plugin.xml file, translations should be put in the plugin.properties file. Extension ID must be used to uniquely identity the translation.

Build file

The build is generated from the plugin.xml file. It is needed to pack the current feature. Each plugin should make the build.xml file up-to-date and commit it. Note that this file needs to be regenerated if the platform doesn't accept it.

Java Code

The plugin code must follow the Eclipse conventions. For the code layout, the JBoss style rules.

Reusability

If you find a construct (Class, Utility or Pattern) that is used more than one time in one of the plugins, it should be factored. The org.jboss.ide.eclipse.core plugin is the place for that. The reusability should also be enforced for UI consistence. This refactoring may come in a second iteration to have a consistent UI across plugins. The org.jboss.ide.eclipse.ui plugin is the place for that. Many examples can be found in the project sources: how to use ImageRegistry, how to use dependencies, etc.

Hints and Tips

In the runtime tab of each plugin, always export the plugin. In debug mode, Eclipse doesn�t care about the scope of classes. In standalone mode, Eclipse is very strict about the scope of classes. Adding a plugin dependency doesn�t mean that classes inside this plugin will be available. This leads to ClassDefNotFound errors in standalone mode.