The plugin services should be available in migrations

[jri]

This easifies writing migrations and is less error prone.

[Jörg Richter <jri@…>]

In b7572f5cd8fd873a89d91de3ff8bfae7213c2888/deepamehta:

Core: inject services into migrations (#324).

Plugin services can be injected into (imperative) migrations by using the @Inject annotation.

Example (an Access Control migration consumes the Workspaces service):

package de.deepamehta.plugins.accesscontrol.migrations;

import de.deepamehta.plugins.workspaces.service.WorkspacesService;
import de.deepamehta.core.service.Inject;
import de.deepamehta.core.service.Migration;

public class Migration5 extends Migration {

    @Inject
    private WorkspacesService wsService;

    @Override
    public void run() {
        // wsService is available here
    }
}

IMPORTANT: the services a plugin's migrations can consume are limited to those services the plugin consumes anyways. If you need other services in a migration inject them to the plugin as well.

See #324

[Jörg Richter <jri@…>]

In 5ed342855656646f686908456aab04f81d334712/deepamehta:

Core: inject own service into migration (#324).

Also the plugin's provided service can be injected into the plugin's *own* migrations.

Example (here an Access Control migration consumes the Workspaces service AND the Access Control service itself):

package de.deepamehta.plugins.accesscontrol.migrations;

import de.deepamehta.plugins.accesscontrol.service.AccessControlService;
import de.deepamehta.plugins.workspaces.service.WorkspacesService;
import de.deepamehta.core.service.Inject;
import de.deepamehta.core.service.Migration;

public class Migration5 extends Migration {

    @Inject
    private AccessControlService acService;

    @Inject
    private WorkspacesService wsService;

    @Override
    public void run() {
        // acService and wsService are available here
    }
}

IMPORTANT: at the time the plugin's service is injected into the plugin's *own* migrations, the plugin is not yet fully activated. In particular (besides others):

• the plugin's init() hook is not yet invoked.
• the plugin's listeners are not yet registered.

Keep this in mind when using a plugin service from within this plugin's own migration.

This particularity only applies to the plugin whose service is consumed by its *own* migrations. It does *not* apply to the *other* plugins whose services are injected into this plugin's migrations. These plugins *are* fully activated.

Note: this particularity is not resolvable as circularity is involved here.

See #324

[jri]

Since we have access to plugin services within a migration there is no need for the postInstall hook anymore. The post-install action can be seen just as another migration. In favor of reduced complexity the postInstall hook should be dropped.

[Jörg Richter <jri@…>]

In 3b4497838ca82b75c6131c14a023b634158e19b3/deepamehta:

Access Control: refactor migrations (#592, #324).

In case of updating an existing installation to DM 4.5: this migration reconstructs the user's memberships by the means of 4.5's Membership associations. This works in particular when several workspaces and user accounts have been created in the pre-4.5 installation.

The Access Control migrations are refactored: the plugin makes no use anymore of both, the postInstall() hook, and the allPluginsActive() listener. These actions performs as migrations now, which makes the control flow and code more clear.

See #592
See #324

[Jörg Richter <jri@…>]

In 237eb289bf4dbd53ba6619fa4f27e44f70f80e2c/deepamehta:

Worspaces plugin: refactor migrations (#324).

The Workspaces plugin makes no use of the postInstall() hook anymore. This action performs as a migration now, which makes the control flow and code more clear.

See #324

[Jörg Richter <jri@…>]

In 5f0521ae9b6c7c65833babb2fd61eb0febe6934f/deepamehta:

Plugin framework: drop postInstall() hook (#324).

You can do the same with a migration.

See #324