Ticket #840 (closed Defect: worksforme)

Opened 5 years ago

Last modified 5 years ago

missing documentation on the "importModels" configuration line

Reported by: Malte Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.6.1
Keywords: Cc:
Complexity: 3 Area: Communications


To the plugin developer is currently hard to find out what exactly the importance of the following plugin.properties line is:



Next to its meaning, it is furthermore unclear what exactly is to enter there.

I currently think it is the value in the <BundleSymbolicName?> (to be taken from the plugins pom.xml your model depends on/re-uses) that one has to enter for successfull installation of ones own plugin.

If that is correct it would be great if you could add a better explanation for this with some basic info about this into the PluginDevelopmentGuide.

Thanks & Cheers!

Change History

comment:1 Changed 5 years ago by jri

When your plugin's migrations refer to types defined in other plugins, your plugin should declare that dependency by using the importModels property.

As value you specify a comma separated list of the bundle symbolic name(s) of the plugin(s) you depend on. Whitespace after commas is allowed. You can find out the bundle symbolic names e.g. by executing "lb -s" in the Gogo shell.

The effect of this propery is that DM installs all the plugins you depend on before installing your plugin. This ensures all types you refer to exist already in the database.

Omitting this property might cause "Type Not Found" exceptions.

The most common case for using importModels is when your plugin's types bring their own icons. In this case your plugin's migrations will refer to the dm4.webclient.view_config and dm4.webclient.icon types. These are defined by the Webclient module. So you have to import the de.deepamehta.webclient model.

3rd-party plugins (not being part of the DM standard distro) are not strictly required to define the importModels property at all, because at the moment you install a 3rd-party plugin all DM standard plugins are usually installed already.

comment:2 Changed 5 years ago by jri

With importModels you actually say: "My plugin must not be INSTALLED and ACTIVATED before these other plugins are INSTALLED and ACTIVATED".

INSTALLING includes e.g. creating the Plugin topic and running migrations.
ACTIVATION includes e.g. triggering the init() hook and registering the event listeners.

So, also the ACTIVATION aspect might create subtle plugin dependencies that can be resolved using importModels.

In that broader sense it becomes clear that importModels is actually not a concise name as it covers only the INSTALL aspect, in particular running migrations (which create the data model).

comment:3 Changed 5 years ago by jri

  • Status changed from new to closed
  • Resolution set to worksforme
  • Milestone Release 4.7 deleted

For the documentation aspect see #444. I added a reference to this ticket there.

Note: See TracTickets for help on using tickets.