I think that using VertexFrame subtypes is the right idea, but I don't think that we need to worry about the JBDS plugin yet at this point. I don't see any technical blockers to doing the first part and then building the API for the Eclipse plugin later, which would need to provide a more specialized approach anyway and as you said, should not be tied to the Model types.

I think that manual conversion is the way to go. I think that dealing with annotations in this particular case would be too complicated for the "benefit."

First approach I think is good. Though I guess it depends on what types you're talking about specifically. Simply adding the types is not enough - we also need to add rules that will populate the graph with these types/interfaces.

~Lincoln

On Thu, Jun 19, 2014 at 8:15 AM, Ing. Ondrej Zizka <zizka@dynawest.cz> wrote:

I've looked at the legacy API.
It's based on legacy Windup types tree, namely FileMetadata.

We could replace these subtypes in the existing API with
WindupVertexFrame subtypes.
Or restrict it on FileModel.
This approach could speed up morphing the Eclipse plugin to new Windup.

On the other hand, I belive that we will want the plugin to show also
non-file-based data, so some API like Ian described in WINDUP-91 would
be more appropriate - more general, and detached from the Model types.
Which is good, IMO.
We would need either manual conversion from graph content to that, or,
better, some mechanism for that.
Maybe some annotation based could do the work sufficiently - i.e.
provide some mapping from Frames to that RuleMatch API.

The question is, is the first approach worth creating as intermediate step?

Regads,
Ondra
_______________________________________________
windup-dev mailing list
windup-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev

--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."