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.
"Freudian slip" ?
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.
Why? (The QVT architecture describe a coupling, why not in a (future
complete) eclipse style implementation ?)
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 find this too big for such an easy thing.
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.
Why is it better to depend from one plug-in in UMLX rather than one
plug-in in declarative QVT....?
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
_______________________________________________
m2m-dev mailing list
m2m-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-dev
Regards,
