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.
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.
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.
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).
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.
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:
- 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.
- 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.
- 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.
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.
TBD. We are hoping to have some early version of this framework available and integrated in Tigerstripe by end of March'08.
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.
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.