Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Tigerstripe On-Going"
m |
(→Generic Annotations) |
||
| Line 31: | Line 31: | ||
== Generic Annotations == | == 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: | ||
| + | # '''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. | ||
| + | |||
| + | === 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 == | == "M0-driven" Generation == | ||
Revision as of 17:47, 15 February 2008
This page is intended to provide a update on current tasks and activities that the Tigerstripe team is focusing on.
Contents
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:
- 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.
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.