Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt.dev] RE: [modeling-pmc] Re: MDT/OCL Text Editor and EMFT Model Registrysuggestion 
Hi, Ed,

See some comments in-line, below.

cW

On 2-Feb-09, at 11:28 AM, Ed Willink wrote:


Hi Christain


Does the EMFT Model Registry component propose to release with
Galileo?  It's too late to "officially" join the train, but that may
not be critical.  Will it be incubating in this release?  Or,
would it
be ready to graduate in Galileo time?  Will it want more
validation by
other projects than QVT and UMLX before graduating?


I carefully used the phrasing EMFT Model Registry suggestion to
avoid confusion with a formal 'proposal'. If a proposal is felt
Sorry, I didn't mean to use imprecise language. It is quite clear that none of this amounts to a Project Proposal. 



to be the correct approach and a subsequent project is approved,
I think the timescales are incredibly tight for Galileo. The candidate
Agreed. I just wanted to be sure that we were talking about post- Galileo times. 



code is almost unchanged after two years. It has been IP-reviewed
as part of the UMLX to QVT Declarative migration. It has a simple GUI
That needed an IP review? It's all under the same PMC ... the IP team told me that your large parser-refactoring contribution to OCL of some time ago didn't need their scrutiny because you are a Modeling committer ... 



that could be significantly extended. I have recently realised that
the major run-time use case give-me-the-Ecore-for-a-named-EMOF/Ecore- model 
should also respond to give-me-the-Ecore-for-a-named-UML2-model.
How about give-me-the-UML-for-a-named-UML-model? That's what OCL for UML would need. 



I feel that an EMFT positioning may attract other projects to use
the Model Registry and that may influence an API revision. Graduating
in a rush could be a mistake.
Right. As I understand it, the adopters so far are two components? OCL would certainly want to see support for other meta-metamodels than Ecore. 



What do you know
of IMP's plans concerning releasing/graduation?  They don't have a
project plan posted ...  Does the editor require run-time components
from IMP, or is IMP strictly a development-time tooling dependency?
The editor uses 3 IMP run time plugins which in turn have a dependency on WALA. I think the intent was to get all these IBM contributions through the IP process, so that post Galileo there is an easy install. Progress 
seems a bit-hap-hazard; the developers have pressing day-time jobs.


Indeed, like the rest of us.  :-)



Some questions for the Modeling PMC:

The Declarative QVT project is, as I understand it, currently in
incubation.  OCL is not.  To what extent can a non-incubating
component like OCL that is on the train have dependencies on
incubating projects?  Could OCL require an incubation release of a
dependency (0.x.0)?  Obviously, the dependent project would have to
have produced at least a formal release, even in incubation.

What work-arounds might there be?  Could OCL provide an
"example" that
requires incubation and/or non-released dependencies?  I
suppose that,
in the end, it would probably be best to target a
post-Galileo release
of the editor?


QVT OML has a similar problem through its use of QVT models from
the QVT Declarative project. The proposed solution is that QVT OML
re-distributes the final 0.7.0 models and that QVT Declarative moves
on to 0.7.1 thereby avoiding a version conflict.
For Galileo, OCL could provide an 'example' that re-distributed IMP bits and the editor and registry either in their current QVT Declarative locations, 
or in their future post-Gaileo locations.
Yes, that's really the crux of my question to the PMC: what can the it's-just-an-unsupported-example distribution do with incubating code and code that is still in the IP process that "core" run-time code cannot, if anything?
OCL is a popular project, so having OCL as the official source of off-train 
shared code could help other projects.
If the train is willing to accept such code. Again, a question for our PMC. 





	Regards

		Ed Willink


_______________________________________________
mdt.dev mailing list
mdt.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt.dev


--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx

Back to the top