Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tigerstripe-dev] Update on API(s)

Hi Richard,


Welcome back J!


Here’s an update on what I did over last week:

-          I decided to split (logically only) the Tigerstripe API in 2 APIs:

o        The I-API for Infrastructure API, dealing with all projects and projects components, generation, etc…

o        The M-API for Model API, to create/edit/maintain model components.

This is only a logical split, which makes it easier to “talk about it” at least.

I’ve created a Wiki page for that too:

-          I’ve made some progress on the I-API

o        Implemented the IWorkingCopy interface (See on wiki page) for ITigerstripeModelProject and ITigerstripePluginProject.

o        I added some JUnit tests for that and some snippets on the wiki too.

-          I’ve made progress on the “new EMF-based” M-API

o        Basically, I realized that the M-API as refactored is good enough. The next iterations should only be concerned with using the EMF framework. In fact, using EMF-generated code I’ve been able to recreate interfaces really close to what we have now, which means the Tigerstripe plugins shouldn’t need more changes. I’ve tried to put out a plan for the migration, see for more details. Feedback more than welcome.

o        Created the ECore for our metamodel and started implementing the POJO persistence through the EMF persistence API (I only provide VERY basic support for ManagedEntities, but the framework is in place, including transactions, refactoring, etc… i.e. some of the touchy stuff. The rest should be pretty mechanical.)

o        Also implemented the basics to use EMF Transaction as part of the API. The result is very slick I think compared to the old one. I’ve put together a bunch of JUnit tests and some snippets on the wiki.

-          I’ve updated the wiki quite a bit: the metamodel, the APIs and the current plan/task ( to give a bit of visibility to everybody.

-          What we need now is a release plan. I think a 6-wk cycle would be good, and we’ll need to go thru the drill once of releasing a version (according to Eclipse guidelines). I was hoping to have it ready by EclipseCon but I doubt we’ll get QDox approved early enough.

-          3rd party .jar files:

o        Velocity was approved and was checked in (I removed it from the .cvsignore)

o        QDox: we got one new committer’s response, but we need one more L.

-          Builds:

o        I haven’t updated the scripts yet but the code now needs an additional plugin to build:

§         Org.eclipse.tigerstripe.metamodel which contains the ECore and EMF generated code.

o        I’m planning to start a nightly this week, although we can’t push them to the Eclipse site yet. We will use the internal Cisco server for now and post releases to the if needed.

-          M0-Driven Generation: read on about it. I need to make some progress on this for a demo the week after next.

-          So it’s probably time to do a bit of testing! In the dev env for now, on a upcoming build (Tuesday?).


I think that’s it!


Let’s go over all this during the community call tomorrow.


Eric Dillon
Technical Leader
Modeling Team/NMTG

Phone :+
Mobile :+1.206.412.0733

Cisco Systems, Inc.
Mail Stop SEA1/5/

2901 Third Avenue

Seattle, WA 98121



This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


Back to the top