Modularization of Web Client needed for customer specific developments

Description

We have customers interested in MDM 5 based MDM solutions. Often it is considered to be problematic being forced to publish any components developed for a specific customer. Customers might rather consider MDM 5 as an unsuitable solution for their purpose and look for alternative solutions because of this situation.

The EPL requires any changes to EPL licensed code to be published again and in combination with the whole web client being one EPL licensed bundle causes this situation. Of course it would be possible to make a change to the web client introducing a plugin point and only publish this changed web client bundle but not the acutal plugin component with the customer specific functionality. But I am convinced, that it makes more sense to have an EWG centred approach to this, rather than have every next customer's developer introduce new plugin points in an "uncontrolled" and unstructured way.

Therefore I propose an approach, to identify relevant plugin points in the web client on the level of the EWG first. Afterwards these plugin points should be introduced into the web client core bundle and it needs to be made sure and likely commonly specified, how the bundling of the core and the additional plugins into an MDM 5 deployment can/needs to be done.

An example with a major importance is the possibility to add additional tabs into the web client's UI providing specific functionality. Just like it was possible in an Explorer in MDM 4 for example. As a specific example here, one could introduce this plugin point into the web client core bundle and create an additional FileExplorer bundle. But basically most MDM 4 functionality like the test planner or XY-Chartviewer needs such a plugin point. I don't think it makes a lot of sense to merge all this functionality into one big EPL licensed web client bundle.

Acceptance Criterias

Accepted if at least a base set of plugin points (minimum an additional tab plugin point) is available in the MDM 5 web client bundle, where developers could implement additional plugins for without being forced to publish all of them. Also a specification of the configuration/bundling mechanism to deploy a web client with a specific set of functionality has to be provided for this epic.

Assignee

Unassigned

Reporter

Markus Renner

Labels

None

openMDM Process Step

00-Global non-functional Requirements

Business Value

None

Eclipse Project

MDM@Web

Components

Priority

Critical

Epic Name

Modularization of Web Client