| RE: [m2m-dev] QVT models component |
|
Hi
Quentin
I think you need
to reread the QVTo specs.
Concerning QVTBase, for me, it is *not* relevant to all QVT languages (only to the declarative part i.e. Relations and Core)! I think you are maybe considering the old versions of QVT (ptc/05-10-02 or even ad/2002-04-10) but in the latest (ptc/07-07-07), any QVT OM dependency to QVTBase has disappeared! 7-7-7 in
8.2.1.1 has
refined :
Transformation [0..1]
Indicates a relational transformation (see Chapter 9: Relations) being refined by this operational transformation. relation : Relation [0..*] {composes, ordered} The ordered set of relation definitions (see Chapter 9: Relation) that are associated with the mapping operations so QVTo depends
on QVTr.
I don't think a
MDT-QVT-OM only user should have to include MDT-QVTR; particularly while the two
MDT
projects use very
different implementation approaches.
As a consequence of everything above, for me, nothing remains truly common to all QVT languages. And it can be easily divided in the relevant components. You are using
'plug-in' and 'component' interchangeably. They are very
different.
I am arguing very
strongly against 4 or more QVT model components. 4 or more components requires 4
or more project plans, repositories, .... etc etc.
I am only arguing
weakly against 4 or more QVT model plug-ins.
I think EQVTBase, EQVTTemplate, EQVTCore and EQVTRelations hosted in the declarative QVT component is a good solution. For QVTR perhaps.
For QVT-OM very definitely not.
One plug-in for each model seems quite clean! Doesn't it? It's a
possibility, but the plug-ins are rather small, so it is potentially an
over-design.
QVTcore support is currently allocated the QVTR project, so from the point of view of the QVT-OM project everything should be in one place, prusumably not part of QVTR. I don't
understand this comment.
The overhead of some irrelevant modules should be a comparatively moderate bloat for QVTR compared to many other Eclipse bloats. The EQVTo models were first added a couple of months ago, and then retracted while IP issues were resolved. They returned again last night. If the QVTo bloat is a significant problem then packaging needs serious consideration. Perhaps a QVT infrastructure component is needed. I don't
understamnd what is big or easy.
M2M has already a structure in which it seems easy to incorporate your work, so what is the advantage/your interest in changing it? Let's keep it simple! Your simple
solution is only simple for QVTR.
But for such considerations, I
would also be interested in the opinion of the project lead...
I would be reluctant to place the models within specific projects since the models are more widely used: a) Open Canarias currently use the models for their QVTcore and QVToperational support. b) UMLX graphics re-uses the QVTr models, but does not (yet) re-use QVTR. I don't
understand this comment. The whole point of this exercise is to move re-usable
material out of UMLX,
which is a dark
IP-suspect corner, into a well-defined sensible shared area, where it may
be referenced by:
1)
QVTR
2)
QVT-OM
3)
UMLX
4) Open
Canarias
....
The EMOF mapping support seems interesting but wouldn't it be relevant that you propose it to EMF? (This is not QVT specific! Is it?) Actually, I am seduced by the idea of Eclipse as a clean framework allowing reuse of its components, thus having every thing in its place (idem for EssentialOCL > MDT OCL). I'm not keen on
raising yet another component creation request. As a result of EclipseCon, I
have far more work to do than I have time for. I do not need yet more
adminstrative difficulties. You forget that you are fortunate enough to be able
to pursue interesting activities almost full time. Many other Eclipse
contributors work largely in their own time.
Regards
Ed Willink
|