close

Filter

loading table of contents...

Blueprint Developer Manual / Version 2101

Table Of Contents
4.1.6.2.3 Working with the Plugin Workspace

Like the Maven workspaces for the other (Java) CoreMedia applications, the workspace resulting from the Studio Client plugin archetype can be built independently from the Blueprint workspace. For example, it does not reuse a parent POM of the Blueprint workspace. This is important, so that your plugin can be updated and released independently of your Blueprint customizations and a concrete CoreMedia release.

All dependencies on Studio modules that are already part of studio-app must be set to provided. For Studio Client, you will only use non-provided dependencies, that is compile dependencies (which is the default value for scope), for the following cases:

  • For plugin-specific third-party modules

  • For splitting a large Studio plugin into several modules

  • For a utility module reused by different plugins

Note that unlike plugins for Java applications, Studio Client does not support dedicated class loading per plugin, and thus all plugins use the same version of a shared code module.

If you have two plugins that use a common shared code module, but can be used independently of one another, each of them must bundle the shared code module (that is, specify a compile dependency on that module, so that it is added to the plugin's ZIP artifact). It is allowed to use plugins with "overlapping" modules, but consider that when all plugins are extracted into a common folder, only one copy can "win". Thus, using different versions of shared code modules is strongly discouraged, as it may lead to spurious errors at runtime.

Apart from this special treatment of dependencies, a Studio plugin workspace is used just like a normal Studio plugin in the Blueprint workspace. You build it with mvn install, resulting in JavaScript files and resources in the target directory and an swc artifact. What is different is that by specifying the goal package-plugin in the POM, all resources needed by the plugin are gathered in the subfolder target/app and an additional artifact (a zip) is created that contains all these resources. This artifact is installed, deployed and released like any other Maven artifact, so it can be used to produce a "binary" release of your Studio Client plugin.

The POM created by the archetype also contains configuration to conveniently test the local development state of your plugin. You need a ready-to-run Studio Client as described in Section 4.3, “Build and Run the Applications”.

If the feature you develop as a plugin also plugs into Studio Server (which is a common case), take care that this Studio Client is connected to a Studio Server including the corresponding plugin. To activate your Studio Client plugin, you have two options:

  • If you want to use the Studio Client Docker image, you only need to mount your plugin's target/app directory as a volume under the path configured in the Nginx server running in Docker, namely /coremedia/additional-packages/plugins. Then, run the Docker image, and Studio Client will pick up your plugin.

  • If you want to run Studio Client from your Blueprint workspace via Maven, you must configure the path to your plugin's target/app directory via the system property additionalPackagesDirs, for example like so:

    mvn jangaroo:run -DadditionalPackagesDirs=~/workspace/my-plugin/studio-client/target/app

    You may specify multiple additional package directories as a comma-separated list.

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.