The services.xml file
Prev | Chapter 18. Implementing a Simple Plugin | Next

## The services.xml file

A "service" is a mechanism by which one plugin can work with other plugins and avoid a bidirectional build-dependency. For example, the XML plugin "depends" on Sidekick, but in fact, it is SideKick which creates and operates on an object (a `SideKickParser`, in fact) defined in the XML plugin. In a way, the dependency is bidirectional.

Similarly, the SshConsole plugin defines but does not instantiate a `Shell` object. It is the Console plugin which creates a specific shell for each available service. SideKick and Console use the `ServiceManager` to search for services offered by other plugins.

Here is an example of a service from the XML plugin, which extends Sidekick:

    <!DOCTYPE SERVICES SYSTEM "services.dtd">
    <SERVICES>
        <SERVICE CLASS="sidekick.SideKickParser" NAME="html">
            new sidekick.html.HtmlParser();
        </SERVICE>
      [...]
    </SERVICES>

The value of the `CLASS=` should be a base-class or interface of the object that is returned by executing the beanshell factory method enclosed in the `<SERVICE>` tag.

In the case above, the returned object tells Sidekick how it can parse files of a specific type (HTML). The API docs for `SideKickParser` should indicate precisely which methods must be implemented in a plugin which offers this service.

For more information about services, refer to the ServiceManager class API documentation. There, you can find out what the tags and attributes mean, as well as how to register and use services. You can also inspect the `services.xml` file of jEdit core to see what services are offered by jEdit itself.

Prev | Up | Next
The dockables.xml Window Catalog | Home | The QuickNotepad Class