Let plugins implement services specified in other modules

[jri]

Together with #835 this would allow for more complex use cases.

[jri]

In c61913d07ce644b90bcb3730f45ea6ada09dab04:

New @ProvidesService annotation (#836).

A plugin can implement an OSGi service which is specified in other module.
This allow for more complex use cases.

BREAKING CHANGES

A service interface must no longer extend PluginService.
The PluginService interface is obsolete and dropped.

Furthermore a service interface must no longer be located in the plugin's service package.
It can be located at arbitrary locations, even in other modules.

To tell DM which service a plugin provides its main class is now to be annotated with @ProvidesService.
The annotation argument is the service interface (a Class object).

Example:

import de.deepamehta.core.service.ProvidesService;

import de.deepamehta.plugins.config.ConfigService;

@ProvidesService(ConfigService.class)
public class ConfigPlugin extends PluginActivator implements ConfigService {
    ...
}

See #836.

[jri]

In 477f3f3c6754cb4debcb58bcd22081e17969cb6a:

Drop @ProvidesService? annotation (#836).

Sorry, change of plan: the @ProvidesService? annotation is dropped after all.

BREAKING CHANGE

New rule for recognizing which service interface a plugin implements: among the interfaces implemented by a plugin the service interface is the one whose name ends with "Service". No annotation is needed. This is more "Convention over Configuration" like.

The service interface can be located anywhere (even in another module), but the convention is for it to reside in the plugin's main package. The package "service" has no special meaning anymore, and, according to the convention, is not used anymore.

See #836.

[Jörg Richter <jri@…>]

In 8ff4c2953b65917ac6abb7c5799819fe35a841a6/deepamehta:

Remove "service" packages (#836).

Adapt standard plugins to convention: a plugin's service interface resides in the plugin's main package.

See #836.