Tigerstripe Roadmap 2008

< To: Tigerstripe Project Status

This roadmap is intended to cover the first 6-9months of Tigerstripe as an open-source Eclipse Technology project. It will be adjusted as the community grows and drives more requirements.

The roadmap is organized around a set of themes that will be implemented through a number of Bugzillas and scheduled over time.

Finally, we are planning to use a sizable part of this period to graduate from Incubation. During this period we will work on adopting all of the Eclipse Processes and best practices, both from a coding perspective than from a release perspective.

Initial Open-Source Release

Our first priority on the roadmap is to provide continuous support to our existing user community. As part of the open-sourcing of Tigerstripe, a few things have to be taken into account:

• Namespace Change: the namespace used in the code is now org.eclipse.tigerstripe.*. As a result, the API that was exposed to write Tigerstripe Plugins has changed, and all existing plugins need to be adjusted to take that change into account. We will provide stable builds of the new version as soon as possible, and will provide support as needed. Please contact us through the newsgroup if you run into any problem.
• API Stabilization: during the first few builds we will work towards stabilizing an initial API for Tigerstripe. While many areas should be addressed, the initial releases will focus on the API "Model Handling". Other areas of the framework will be addressed over time.
• Extension Points: another consequence of the namespace change is the change in all existing Extension Points provided by Tigerstripe.
• Change of Licensing: the EPL license is now used for Tigerstripe.
• No more License Key: where the commercial version required a license key to run, the open-source version doesn't. As a result the role-based configuration of Tigerstripe (which was handled through the license key) needs to be revisited.
• Initial Release & Numbering: Tigerstripe is now an incubation project. Consequently, upcoming releases must be 0.x.x versions until the project graduates out of incubation. The first release will be 0.2.2.5 (2.2.4 incremented / 10). The release date for this initial release mainly depends on how quickly we can clear the requirements from Eclipse Legal with regards to some of the 3rd party .jar files we need to re-distribute with Tigerstripe.
• tigerstripedev.net migration: all the resources and documentation available on the old website will be migrated to the Wiki

Transition from a Commercial Tool to an Open-Source Framework

We acknowledge that there is a big difference between a commercial tool and a successful Open-Source Framework. It is not simply about dumping some existing code into the open-source community, it requires not only a mind shift of the contributors, but also an adjustment of the content and philosophy of the final environment.

To that end, we are going to review all changes with this theme in mind.

In practice, this means:

• Published, stable, and documented APIs: at every level in the framework, we will ensure that published API will remain stable and well documentated, as this is a key for the framework to be used as the basis for more development/extensions.
• Flexible extension mechanisms: in its initial contributed version Tigerstripe had a set of built-in components limiting users in what can be achieved with the framework. Published Extension Points will be added for these components to allow users to build on top of the framework.

Legacy Code Migration

Because Tigerstripe was developed over the past 3 years in a closed-source environment, the code contains some legacy code that should be replaced with the latest corresponding components from existing Eclipse projects.

While this will be done over time, these changes should not impact users of the framework as we will make sure that published APIs will remain consistent.

There are a number of smaller tasks that would belong to this category, but the highest priority will be to replace the internal "proprietary core" of Tigerstripe by a complete EMF-based core.

The candidate legacy components to be migrated initially are:

• Old legacy [OSSJ] built-in generation: in its initial version Tigerstripe included a generation feature especially targeted for OSSJ Guidelines. This code is now obsolete and deprecated and should be further removed/migrated in the source base.
• Proprietary runtime Model implementation: while most of the Tigerstripe plugins are based on current Eclipse components from other projects (GMF, e.g.), the core should be based on EMF, and the corresponding .ecore for the Tigerstripe Metamodel should be published.
• Headless runs without Eclipse: in the commercial version, Tigerstripe could be run from Apache Ant or Maven, or the command line so that the generation could be integrated in a continuous build environment. While this feature should remain, its implementation should be refactored to run within a true headless Eclipse instance as opposed to running in a simple JVM. This will allow to make better use of Eclipse Extension points and simplify the start-up process.

Framework Enhancements

Framework enhancements will first target the extensibility of Tigerstripe so that the framework can be better tailored to more use cases.

In particular, we will investigate enhancements in the following areas:

• Generic Model Annotation/Decorations: the current annotation mechanism is based on a principle similar to UML2 Stereotypes, which are defined in a Tigerstripe profile and later stored with the model. This has a few limitations including the cluttering of the model, the fact that read-models cannot be further annotated and that decorating a model isn't very user friendly in the UI. A generic mechanism to annotate a model would allow users to use specific extension points to define generic annotations.
• Meta-model extensions: as part of the refactoring of the Tigerstripe Core to use EMF (see above), the new .eCore should account for meta-model extensions, allowing users to fine-tune the meta-model.
• Model Persistence Customizations: the current persistence mechanism for Tigerstripe model artifacts uses a proprietary format based on annotated java files. The persistence format should be more flexible and configurable through an extension point. Currently, 2 other formats are considered: a pure EMF-based XML format or an SML format.
• Making Tigerstripe plugins "true" plugins: in their current definitions Tigerstripe plugins aren't proper PDE plugins. A set of extension points should be defined to remedy to this an fully leverage the PDE environment.

Community Build Up

While Tigerstripe starts with an existing user community thanks to its prior life as a commercial product, it is essential for the success of Tigerstripe as an Eclipse project that a true open-source community be assembled around Tigerstripe.

We are planning to set up a series of face-2-face meetings, webinars and various training material to get people more familiar with the new Open-Source Tigerstripe.

The first iterations will target the existing user community through the [TeleManagement Forum]. Also, we will be working with other Eclipse project to explore collaboration areas.