Re: [stp-dev] takin' a look at the core model code

[Daniel Berg <danberg@xxxxxxxxxx>]

Oisin,

This is a pretty good high-level overview
of the contribution.
We are working on some documentation
to help people get started with using the APIs.

Yes we do plan to do further refactorings
on the code.  This shouldn't be considered code complete by any means.
 We are also working to get our POJO support factored so it can be
contributed.  Hopefully this will happen next week.

Regards,
Dan

Oisin Hurley <ohurley@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

03/31/2006 04:09 AM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	[stp-dev] takin' a look at the core model code

Myself and a few of the IONA guys spent some hours
going thru the
core contrib yesterday [0], and here's a quick report on what we
found.

Whatever about the plugin/package organization of the code, it looks
like there are four logical parts to it: the core model, the  
introspection
framework, some model resource management stuff and some edit support
stuff for the model (although I'm not sure about the relationship
between the last two).

The core model is clear enough - it's an EMF model, based off a set
of schemas. It's decorated a bit compared to the SCA official 0.9
public doc, with some extra classes, enums, etc that are basically
practical adaptations that are useful for condensing common function
and the like.

The introspection framework supplies the one extension point that
is available - it allows you to construct an introspector for a
file resource with a certain extension. Introspection is a one of
the key features in the assembly approach - its purpose is to allow
developers to put in as much information and hints relevant to
assembly into the code itself, rather than having to produce
extra metadata files. The contrib contains an introspector for
'.module' files (plus a test introspector in the units) and I
believe that Dan et al. will be contributing a '.java' inspector
later in the play.

I think the introspection process is going to be a very important
factor in making STP applicable to many existing approaches to
SOA tooling - there doesn't seem to be any reason why you couldn't
write an inspector for any language/model of your choice.

The resource management and edit support (as embodied in the
*Scribbler* source) we didn't drill into that deeply - some intro
documentation on that part would be great guys, if you could dig
out a few paragraphs!

There'll be more questions later as we get more familiar with
the content. I've spotted a few places in the code where a refactor
would work some good things - Dan do you guys have any plans to do
more refactoring work on the bugzilla submission?

  cheers
  --oh

[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132747
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev