Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt.dev] RE: [modeling-pmc] Re: MDT/OCL Text Editor and EMFT Model Registrysuggestion

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
to be the correct approach and a subsequent project is approved,
I think the timescales are incredibly tight for Galileo. The candidate
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 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.

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. 

> 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.

> 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.

OCL is a popular project, so having OCL as the official source of off-train
shared code could help other projects.

	Regards

		Ed Willink




Back to the top