Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Tigerstripe OSSJ

< To: Tigerstripe_FAQ
Since its first versions (including the commercial version prior to open-sourcing), Tigerstripe has been providing built-in support for OSSJ.

As of 0.3, the support for OSSJ has changed. Starting with 0.4, OSSJ will not be supported anymore by Tigerstripe, shifting focus to the TMForum Interface Program instead (TIP).

Built-in OSSJ Generators

The built-in OSSJ generators that were shipping with the commercial version of Tigerstripe Workbench were based on very old version of the OSSJ Design Guidelines. These were no longer supported by OSSJ.

Since 0.3, they have been removed from the distribution. This includes all 3 generators (Java, XML and WSDL).

Core OSSJ Classes

Up to 0.3, ALL Tigerstripe Model projects were created with a default context that contained the Core OSSJ classes, such as javax.oss.ManagedEntity, etc... In practice, Tigerstripe Workbench was adding (and hiding) a reference to a Tigerstripe module that contained these definitions to every model project. This module wasn't explicitly copied into each project but rather a reference to a hardcoded location was created.

Since 0.3, the hardcoded module was removed from the Tigerstripe distribution, and the reference is not created anymore.

Models projects created with a version prior to this change that were referencing these OSSJ Core classes (e.g. Tigerstripe models for OSSJ APIs) will become invalid with Tigerstripe 0.3, because the corresponding definitions cannot be resolved. The hardcoded module simply needs to be added by hand to the existing project to resolve the dependencies. This module can be downloaded from Tigerstripe OSSJ.core.model-1.0.6.zip.

Note that model projects that weren't explicitly using OSSJ Core Classes will not be affected.

OSSJ Specifics and Tigerstripe Profiles

Up until 0.3, Tigerstripe was configured by default to expose all OSSJ specifics built into the Tigerstripe Metamodel. It was possible to turn them off (and hide the corresponding functionalities from the Tigerstripe UI) by defining a Tigerstripe Profile that had these options "un-checked".

Since 0.3, the behavior was swapped: by default, no OSSJ Specifics are shown in the UI, but a Tigerstripe profile can be used to re-activate them.

OSSJ Specific Properties

All properties that were captured as part of the project (in the tigerstripe.xml descriptor) were migrated to the relevant OSS/J Generators.

Back to the top