Tigerstripe On-Going

< To: Tigerstripe

This page is intended to provide a update on current tasks and activities that the Tigerstripe team is focusing on.

Tigerstripe API Refactoring

As an initial step on Tigerstripe as an open-source Eclipse project, we are now doing quite a bit of refactoring on the Core Tigerstripe API. Fundamentally, the existing API had evolved over time and wasn't necessarily complying with all patterns and conventions of Eclipse projects.

To ensure that Tigerstripe would be successful in the long run, we wanted to ensure that this API would be stable and reliable. It seemed natural to begin the open-source process by such a refactoring activity.

Goals

The main goals for this refactoring are the following:

• Explicitly separate the public API outside an "internal" package to allow for:
  • Tigerstripe project editing & lifecycle management, including more robust support for multi-threaded environment, and editing.
  • Access/Edit a model programatically. The existing API was based on a metamodel that was implemented manually (i.e not with EMF). We are planning to eventually migrate to a full EMF support for the meta-model, but will be migrating gradually. The first few steps will consist in making changes to get closer to an interface as it would be generated through EMF. The goal is to have complete support for an EMF-based meta-model.
• Consistent naming and patterns
• Javadoc and code snippets.
• Remove the distinction between the old "internal" and "external" API.
• Hide completely the persistence mechanics for all elements (model artifacts and other Tigerstripe elements such as projects, facets, etc...)
• Remove deprecated code.

Impact

Because the initial change will include package renaming, class/interface and method renaming, it is anticipated that existing Tigerstripe plugins will need to be migrated as well. However, due to the fact that as part of the open-sourcing, the contributed code was renamed from "com.tigerstripesoftware.*" to "org.eclipse.tigerstripe.*", migration was already required, which is why it made more sense to include so many changes in the API in "one go" upfront.

Progress

The current stage of the refactoring is as follows:

• The old "external" and "internal" APIs have been merged into a single Model Management API.
• This model management API was moved to the org.eclipse.tigerstripe.model.deprecated_ package as it will eventually be replaced by a fully functional EMF-based API. This temporary API though is almost identical to the planned final EMF-based API, meaning that only minimal changes are anticipated to plugins in the future.
• Project Management was cleaned up quite a bit, using a mechanism based on "Working Copies" to support editing/persistence without exposing the implementation details as it used to be.
• The main "API" singleton which used to provide access to a number of "Session objects" has been simplified into a "TigerstripeCore" singleton with a number of static methods (similar to the well know JavaCore class).

Stabilization

Because Tigerstripe is used in production in a number of environments, it is important that this API stabilizes quickly. The current plan is to be near finished (except for the EMF migration) by March 3rd, 2008.

Generic Annotations

Background

The Tigerstripe Metamodel is derived from UML and as such includes the concept of Profiles and Stereotypes allowing to build additional metadata into a model.

Typically, this metadata is consumed by Generation Plugins to trigger a specific code generation depending on the target.

However when large models are used to generated numerous artifacts, the number of "Stereotypes" used to annotate the model as a tendency to explode rapidly, which make it difficult to manage.

Fundamentally, model annotations should allow to decorate a model with meta-data, but should be kept separate from the model. This is the basic requirement for building a generic Annotation Mechanism for Tigerstripe. In fact, this annotation framework is intended to address 3 shortcomings of typical stereotypes:

1. Stereotypes are stored with the model. After a while, these tend to clutter the model. Considering they are only relevant in specific Plugin generation contexts, it seems they should be stored separately so they can be distributed with the model only to relevant users/consumers.
2. Read-only Tigerstripe Models can't be further annotated. Tigerstripe support a model sharing mechanism where users can share a "read-only" version of a model. Since the shared model is completely read-only, end-users can't add/edit Stereotypes in that model and can't use it to generate additional artifacts. With Annotations stored separately from the model, this limitation goes away.
3. UI is tedious with Stereotypes: considering some people are only concerned with annotating models and have to edit numerous attributes in large models, the current UI makes it very tedious and error-prone. A simple UI based on a dedicated view (similar to EMF properties view, e.g.) that would be linked with selections in the workspace would be a lot more convenient.

Progress

An initial Proof-of-Concept is available in CVS (org.eclipse.tigerstripe.annotations and org.eclipse.tigerstripe.annotations.ui).

The intent is to make the framework completely generic, i.e. allowing to build annotations on any URI in the workspace with the necessary extension point to further integrate it for dedicated purpose. The current POC allows to "annotate" any IResource in the workspace transparently, out-of-the-box (try deploying the org.eclipse.tigerstripe.annotations.sample plugin for an example).

We are now drawing the conclusions from this POC and doing a proper design around the use of EMF and a DSL for the definition of these annotations.

Expected Release

TBD. We are hoping to have some early version of this framework available and integrated in Tigerstripe by end of March'08.

"M0-driven" Generation

Overview

Up until now, Tigerstripe's generation plugins were of one kind only, allowing to walk a model to generate code, documentation or any template-based file. In other words, the generation in Tigerstripe was based on the "M1" level (that is the classes defined in a model).

Increasingly, we have been asked whether we could support "M0"-driven generation, i.e. allowing to generate files based on instances that would be created out of a model.

There are two aspects to consider in this context:

• Creating a set of instances out of a model in a semi-automated fashion. We are still investigating this part, but our initial thoughts are around the use of a Tigerstripe Facet to define a set of Classes to be instantiated. The instantiation would be done in an Instance Diagram so it can be further refined manually.
• Generating from a set of Instances. This aspect is looking into driving plugin rules from a instance diagrams. The instances contained in that diagram would be the context for generation.

This has some very obvious applications like:

• Generating test data sets complying with a model
• Generating instances of services or resources modeled in a Tigerstripe model so they can be provisioned and deployed automatically.
• etc...

Progress

This activity is only starting. We are at the proof-of-concept stage hoping to generate code out of an instance diagram that was created manually.

Expected Release

TBD.

EMF-based Metamodel & Migration

In the initial version of the contributed code, Tigerstripe's core model management API is based on proprietary code. This code evolved over the last 5 years from an initial POC.

At this stage, the resulting API is sub-optimal compared to a framework such as EMF that is intended exactly for this purpose. Also, being now officially part of the Eclipse community, we want to make sure that Tigerstripe re-uses the best practice and components available from other projects rather than re-inventing the wheel and potentially confusing the community.

Additionally, being able to use EMF natively for Tigerstripe models means that developers interested in extending Tigerstripe with some of the latest EMF Technologies can do so without problems.

Approach

Because this is a rather important change in the Tigerstripe code, we want to make sure the migration is done incrementally so that the integrity of existing models can be guaranteed along the process.

• Phase 0: Initially we will migrate the existing Model Management API ("Old API") to a set of interfaces and methods that adhere to the naming conventions and signatures as found in EMF generated code. This will ensure that existing Tigerstripe generation plugins once migrated to this iteration of the "Old API" will require almost no change to function with the final API ("EMF-based API"). This "Old API" will be place in the "deprecrated_" package from day one, to signal the fact that this is a temporary, un-stable API.
• Phase 1: Define an ECore for the existing Tigerstripe Metamodel, building in the features required for future meta-model extensions.
• Phase 2: Incrementally, we will build up the "EMF-based API" along with the corresponding test suites, to the point that all model management functionalities should be available through the API. Code snippets and examples will be published on this wiki to document the patterns used.
• Phase 3: We will integrate the "EMF-based API" into the Tigerstripe UI, so the UI doesn't make any reference anymore to the "Old API". This phase will provide the final validation for the completeness of the "EMF-based API". At this stage the "Old API" will be officially deprecated. During this phase the final adjustments to existing Tigerstripe Generation Plugins will be required.
• Phase 4: Finally we will remove from the code base the "deprecated_" package hosting the "Old API" completely.

Progress

At the moment, we are wrapping up Phase 0 and beginning with Phase 1. In fact, the Tigerstripe Metamodel is in CVS (org.eclipse.tigerstripe.metamodel).

Expected Release

This is a major task, including re-write of major parts of Tigerstripe. As we want to ensure the integrity of existing models (large models in production in particular) we want to take extra care for this activity.

While we are hoping to reach completion of Phase 2 rather rapidly, Phase 3 will will prove to be true test. Our goal is to have Phase 4 complete by v1.0 of Tigerstripe at the latest.

Project Defined Reference Versioning

Overview

Phase I of Tigerstripe's Buckminster integration is quickly firming up. In Phase II, a modeler must be allowed to specify a version attribute, in addition to the name attribute, of a referenced project. This becomes especially important as the number of project references become non-trivial. This feature is expected to be useful in standard workspace materialization, and when used in conjunction with Tigerstripe's Buckminster headless support.

It is intended that this document will be revised as additional requirements are discovered or initial requirements are determined to be unnecessary.

Requirements

• Add a Tigerstripe Project reference using the Tigerstripe Descriptor Editor -> Dependencies -> Referenced Tigerstripe Projects table. This reference may be identified by name and OSGi based version. An undefined version will default to current workspace (or, in the case of workspace resolution using Buckminster, the trunk/head of scm).
• Write data to the underlying Tigerstripe Descriptor (tigerstrip.xml) file.
  • Question: Require validation before writing, or allow a "dirty" reference? I think allow dirty reference, but mark as error. Opinions?
• Trigger validation to verify that the referenced project is present in the current workspace. This verification will be based on project name and version. This should be re-validated each time a reference is added, modified, or deleted.

On-going Maintenance

Although Tigerstripe is on going a series of fundamental changes (see above) we are very committed to supporting our existing user community and will make sure we address reported bugs and enhancements in a timely fashion.

Initially, we will focus on an initial release of the Workbench, allowing users to migrate over to an official Open-Source release.

Our current plan is start providing builds as soon as Eclipse Legal as cleared our last CQs.