Message
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,