TargetPlatformService Specifications

Nuxeo needs a notion of target platforms for Studio and Connect (and maybe other use cases).

Requirements

• list available target platforms and associated packages
• have a notion of deprecation to guide users of old/deprecated versions
• make it possible to hide/show a target platform live
• allow reusing contributions to the service for automated testing of all target platforms on Studio side

Target Platforms Model

Target Platform Definition

• id (name + version)
• name (missing for now)
• version
• label
• description
• status (supported, dev, soon_deprecated, deprecated) --> this would map to permissions, maybe
• isFastTrack
• available packages ids -> see if reference per id (name + version) or if version can be implicit
• aliases (needed for target platform migration from "DM"
  to "CAP" + "DM" package for instance, can be useful for connect
  versions mappings too )
• target test nuxeo versions (5.8 + 5.8.0-HF08-SNAPSHOT for instance) --> useful for tests
• enabled (boolean allowing to enable/disable a target platform "live")
• restricted (boolean allowing to enable/disable a target platform "live" for some users only)

Target Platform Package

Different concept (packages can be referenced by target platforms) but same metadata.

Also needs a notion of "dependencies" (a package can depend on another one), this notion is not shared with target platforms for now.

Target Platform Instance

It is useful to have a notion of target platform instance (even if interface can be common to the definition) just to handle available target packages vs enabled target packages (and ask the service for a target platform definition handling the notion of "activated" packages).

Satellite Concepts

Several notions are currently useful on Studio side:

• PLATFORM_TYPE (DM, DAM, CMF) useful to list platforms "supporting some features" -> might be inferred from enabled packages ids
• TARGET_PLATFORM_STATUS: list of available status, should define interface for usage and list as contributions to the service (for instance, depending on the status, some tests are not run, or there is a sticker in the UI, etc..)

TargetPlatformService

Configuration

• default target platform, it's interesting not to put this boolean on the target platform definition directly in case there is additional logics to add later on (default target platform depending on some criteria for instance).
  For now only the "cap-5.8" target platform id is needed.

API

• isStrictlyBeforeVersion(TP, String version)
• isAfterVersion(TP, String version)
• isVersion(TP, String version)

+ same with other TP as parameter instead of just version

• matchesPlatformType(TP, PLATFORM_TYPE type)
• getTargetPlatform(string tpId, boolean filterRestricted, (opt) target packages)
• getDefaultTargetPlatform()

API to adapt (used by annotations on Studio test classes for now, might be useful in the future):

• TARGET_PLATFORM[] getAllPlatforms(boolean ignoreDeprecated,
  boolean ignoreMigrated)
• TARGET_PLATFORM[] getPlatforms(PLATFORM_TYPE type, boolean
  ignoreDeprecated, boolean ignoreMigrated, boolean
  ignorePlatformsWithPackages)

Persistence/hot reload

The easiest is to have a directory with additional values overriding values from the XML descriptor (to enable/disable/restrict usage of some target platforms)

A specific tab in the admin center can be made available to list available target platform and change the corresponding "status" (enabled, disabled, restricted)

Studio Target Platforms Model

Additional Metadata

• builders ---> feature types
• registries
• help messages, etc...

+ API (hasRegistry, etc...)

Process would be to query the TargetPlatformService for its target platforms, and then merge them with Studio target platform info (removing platforms unknown to Studio)

Tests

• write a shell or python script that parses the XML file
  contribution to iterate other test classes
• this should benefit both unit and integration tests.

Code Generation

The goal here is to have a single reference file listing available platforms.
If needed, some code generation could be done to generate JAVA classes (or other needed confs) from the reference XML file.