Jump to: navigation, search

Difference between revisions of "Tigerstripe On-Going"

m
(Tigerstripe API Refactoring)
Line 2: Line 2:
  
 
== Tigerstripe API Refactoring ==
 
== 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 ==
 
== Generic Annotations ==

Revision as of 17:30, 15 February 2008

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

"M0-driven" Generation

EMF-based Metamodel & Migration

On-going Maintenance