| RE: [tigerstripe-dev] RE: Update on API(s) |
|
Comments inline. Thanks for the initial
review! You caught quite a few things already. Eric From: Richard
Craddock (rcraddoc) One other..... We still have Stereotypes
in the new met model - won't they be going out, being replaced by the new
Annotations stuff? [ER>] Yes. Stereotypes still make sense for from a
modeling point of view. Annotations are those “decorations” that
shouldn’t live in the model… This is a thin line, but I think we’ll
find it useful. RC From:
tigerstripe-dev-bounces@xxxxxxxxxxx
[mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On
Behalf Of Richard Craddock (rcraddoc) Eric, just taking a look
now..... I like the split of the
infrastructure and model - even if only for clarity of discussion - it will
help. [ER>] That’s what I thought! A few initial comments on
the metamodel.. Why do we have both
IMutliplicity AND EMultiplicity ? [ER>] Shouldn’t be this is a mistake J. Consider this not very stable
at the moment J. Some of the IType methods
need review - we have isDatatype, isEntityType, isEnum - is that sufficient? (I
know its what we have now). Have we lost getArtifact() ? [ER>] same here. Need a bit of review. This is a first
stab at it. Method exceptions are
instances of IType... seems an odd choice to me? [ER>] Hmm… I missed that. This was an initial pass.
Need to be changed indeed. VisibilityEnum should be
EVisibilityEnum for consistency ? [ER>] Yes. Thanks. We get packages :-) -
will we be able to iterate over them ???? [ER>] I think that was a limitation from the previous
model… Let’s fix that. Where do queries fit - I
can't see them on the ModelManager.. [ER>] Well they are not hooked up yet, but they should be
on the ModelManager, which gathers all the IModelRepositories in one single
logical model. . That's just a few
question that spring to mind on first look. Talk to you later, RC From: Eric
Dillon (erdillon) 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: http://wiki.eclipse.org/Tigerstripe_APIs -
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 http://wiki.eclipse.org/Tigerstripe_On-Going
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 (http://wiki.eclipse.org/Tigerstripe_On-Going)
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 tigerstripedev.net if needed. -
M0-Driven Generation: read on http://wiki.eclipse.org/Tigerstripe_On-Going
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
|
