Plugin hot deployment for developers

[jri]

Plugin developers should get hot deployment for their plugin

• Regardless if they build DM from source or using the DM standard distro.
• Without the need to add a config line to global pom.xml (in case of standard distro they don't even have pom.xml).

This would make plugin development more easy for new developers.

Hot deployment here means the plugin is automatically redeployed after each compilation.

[Jörg Richter <jri@…>]

In 31067bd9d28803e550c008c987d47492085b6710/deepamehta:

Plugin hot deployment for developers (#847).

Plugin developers don't need to build DM from source anymore in order to get hot deployment for their plugin.
They can just download and install the DM Standard Distribution.

The Standard Distribution now comes with a "bundle-dev" directory.
This is where you develop your own DeepaMehta plugins.
Create a new directory here for each plugin.
Every time you build your plugin it gets automatically (re)deployed.

The plugin developer is no longer required to add their plugin path to global pom.xml (with the DM Standard Distribution they don't even have pom.xml).

See #847.

[Jörg Richter <jri@…>]

In 439f3e91fa09c3f8f6233427d66a67c1e1192b46/deepamehta:

Change standard plugins hot deploy (#847).

For core developers: There is only one hot deploy directory.
That is called "bundle-deploy" and is created in the repo root directory.
Every time a standard plugin is build it is automatically copied to the bundle-deploy directory.

Pending: don't copy the deepamehta-test artifact (which is not a bunble) to bundle-deploy.

See #847.

[Jörg Richter <jri@…>]

In 5bc78b15027f9d86a4ec2ff827f8ec44ec6f42fb/deepamehta:

POMs: deepamehta-test is not hot deployed (#847).

INTERNAL CHANGES
(not relevant for plugin developers)

Artifact deepamehta-test is derived from deepamehta-global (instead of deepamehta-parent).
Thus it is not copied to bundle-deplopy (= not hot deployed) as it is no bundle.

Elements moved from deepamehta-parent to deepamehta-global:

• <dependencyManagement>
• junit, easymock <dependencies>

deepamehta-parent version numbers are in sync with the DM distro version number (4.8-SNAPSHOT).
Independent versioning (... 5 6 7) is not reasonable as it changes with every distro release.

2 renamed artifacts:

deepamehta-global -> deepamehta-project
deepamehta-parent -> standard-module

See #847.

[Jörg Richter <jri@…>]

In e23b9374a887d1ef23aadc2b7a651753ac484c16/deepamehta:

POMs: revise deepamehta-plugin-parent (#847).

BREAKING CHANGE

1 artifact renamed:

deepamehta-plugin-parent -> deepamehta-plugin

INTERNAL CHANGES
(not relevant for plugin developers)

1 artifact renamed:

standard-module -> deepamehta-module (was: deepamehta-parent)

Revised deepamehta-plugin-parent:

• derived from deepamehta-module instead of (global) deepamehta-project
• delete <properties> (as derived from deepamehta-project)
• delete <dependencyManagement> (as derived from deepamehta-project)
• delete <dependencies> junit and easymock (as derived from deepamehta-project)
• delete 2 plugin configurations:
  • maven-pax-plugin
  • maven-javadoc-plugin
• delete plugin configuration (as derived from deepamehta-module):
  • maven-bundle-plugin

2 plugin configurations moved from deepamehta-module up to deepamehta-project:

maven-compiler-plugin
maven-surefire-plugin

1 artifact added to <dependencyManagement> of deepamehta-project:

commons-io

See #847.

[Jörg Richter <jri@…>]

In 8927738329211762336e4f80360298e3edce995f/deepamehta:

Module POM: uninstall before hot redeploy (#847).

When building a module: the clean goal deletes the artifact from the bundle-deploy directory.
Thus the module is uninstalled before being (re)deployed. This gives dependent modules time to stop.
Once the module is redeployed the dependent modules start again.

See #847.

[Jörg Richter <jri@…>]

In a47e043321a62139126a03b8a81fe33b25117fd8/deepamehta:

Add modules-external directory (#847, #618).

When cloning the DM repo a directory modules-external is created.
This is where you develop your own DeepaMehta plugins.

Create a new directory here for each plugin.
Every time you build your plugin it gets automatically (re)deployed.
You're no longer required to add the plugin path to global pom.xml.

Use the modules-external directory when you've build DeepaMehta from source
and want develop 3rd-party plugins and DeepaMehta standard plugins in parallel.

Note: in order to develop a (hot deployed) plugin a developer don't need to build DM from source anymore.
They can just install the DM Standard Distribution.
See https://trac.deepamehta.de/ticket/847#comment:3

See #847.
See #618.

[jri]

A configuration option needs to be added in case the developer want keep hers plugin sources at a non-standard location (other than "bundle-dev" resp. "modules-external").

[Jörg Richter <jri@…>]

In 96ef7c9e923c02a947e9478cec5e443e296e465b/deepamehta:

Build: introduce dm4.deploy.dir property (#847).

The developer can keep hers plugin sources at a non-standard location (other than "bundle-dev" resp. "modules-external"). In order to hot (re)deploy the plugin every time it is build the developer must add the property dm4.deploy.dir to the plugin's pom.xml. The value is a path to the directory where DM copies the plugin jar to once build.

The path can be absolute:

<properties>
    <dm4.deploy.dir>/home/terry/deepamehta/bundle-deploy</dm4.deploy.dir>
</properties>

or relative (to the plugin pom.xml):

<properties>
    <dm4.deploy.dir>${project.basedir}/../../deepamehta/bundle-deploy</dm4.deploy.dir>
</properties>

The default value for dm4.deploy.dir is ../../bundle-deploy, which is fine in case the plugin sources are kept at the standard location ("bundle-dev" resp. "modules-external").

See #847.
See #846.

[jri]

Replying to Jörg Richter <jri@…>:

or relative (to the plugin pom.xml):

<properties>
    <dm4.deploy.dir>${project.basedir}/../../deepamehta/bundle-deploy</dm4.deploy.dir>
</properties>

Sorry, this was misleading as actually an absolute path is specified.
You don't need ${project.basedir}/
Just write:

<properties>
    <dm4.deploy.dir>../../deepamehta/bundle-deploy</dm4.deploy.dir>
</properties>

The path is relative to the plugin pom.xml

[Jörg Richter <jri@…>]

In dcd3ab1220382f854862e9b1e64ad9f43e338ad2/deepamehta:

Build: add dm4.deploy.disable property (#847).

To disable the plugin from being copied automatically to the "bundle-deploy" directory once build run Maven with the dm4.deploy.disable property:

mvn clean package -Ddm4.deploy.disable

See #847.
See #846.

[Jörg Richter <jri@…>]

In 4093c9c2e1d0d9cd547b56b8f1a59ff4636607c9/deepamehta:

Config files: explain hot deploy directory (#846).

The property felix.fileinstall.dir is more prominent in the config files and has an explanation.

In pom.xml of a from-source installation the property <felix.fileinstall.dir> is located in the global <properties> element (instead of being buried in a <profile> element).
It has its own <!-- Hot Deployment --> section.

Explanation:
DeepaMehta plugins (jar files) from this directory are hot deployed (like any other OSGi bundle).
You can add further directories here, separated by comma.
IMPORTANT: the trimmed value of the <felix.fileinstall.dir> element must not contain any spaces.
Otherwise the first and the last directory is ignored. Line breaks and tab characters are allowed however.

In config.properties of the binary distribution the property felix.fileinstall.dir has its own ## Hot Deployment ## section.

Explanation:
DeepaMehta plugins (jar files) from this directory are hot deployed (like any other OSGi bundle).
You can add further directories here, separated by comma.
Also you can remove the standard directory ("bundle-deploy") if you like.
Line breaks, tab characters and spaces are allowed.
IMPORTANT: if the value of felix.fileinstall.dir spreads several lines the line break characters must be escaped with backslash (\).

See #846.
See #847.