| Re: HA: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2? |
|
Hi Team, Honestly, this is easier to say than to do. If you want to support both specifications I hope you have already thought a wonderful design to support them. I ask you the same question I asked Laurent. Have you thought about if we are going to keep 2 different meta-models (OCL 2.0 compliant and 2.2 compliant). Are we going to keep an OCL 2.2 non-compliant metamodel, just to support the old-fashioned 2.0 specification). If the new specification would imply just adding new features, there wouldn't be any problem, but this is not the case. We must seize the opportunity of stepping on a new major release to 1. Fix the current implementation problems which could imply API breakages. 2. Include API breakages which comes from the new specification changes, specially abstract and concrete syntax changes. 3. Include new features added the by the new specification. If we are not going to completely adopt the new OCL 2.2 specification, I'm sincerely doubting about the need of MDT-OCL 2.0.0 for Helios release. Just go on MDT 1.4.0 and let's add the new features which doesn't make us break API. However, as a pure MDT-OCL committer I don't share this point of view. About the extending languages like QVT (I guess it must be the main reason of your "fears"). 1. I don't think that QVT Declarative, as same as MOF Model2Text (Acceleo), mustn't be worried about a new OCL language. Its abstract syntax doesn't extend OCL concepts. 2. I provide you some information about Mariano's wishes about QVT spec: ">>>
About OCL 2.3 RTF. I guess that you will prioritize the QVT 1.1
RTF ? I guess that
>>>
we (Victor and me)'ll help you in this one before tackling OCL
2.3 issues.
>>>
What do you think ?
Yes, QVT 1.1 should be ready by end of October in order to be presented to the AB at the end of the year. So we have some hard
work in QVT for the coming months.
In any case, If you still want to support the old specification in Helios release, I would like to see ideas or start a discussion about how are we going to do it. Cheers, Adolfo. Alexander Igdalov escribió: Hi all, Clients that wish to work with the implementation of the OCL 2.0 standard will not be able to use MDT OCL 1.3.x in Helios+ releases. This is because OCL 1.3 branch is for Galileo maintenance only and it would be probably impossible to install 1.3 in Helios (for instance because of incompatibility with the future versions of dependencies, e.g. EMF). Therefore, we need to support both standards in MDT OCL 2.0.0. But I think we should mainly focus on OCL 2.2 support. Since then IMO new features should be added to the part of code which supports the latest standard (or the shared part of code). The part of code responsible for OCL 2.0 should be kept for backward compatibility. Thus IMO the latter is to be updated only in case of very annoying bugs and issues like compatibility with the latest EMF changes, etc. Cheers, - Alex. ________________________________________ От: mdt-ocl.dev-bounces@xxxxxxxxxxx [mdt-ocl.dev-bounces@xxxxxxxxxxx] от имени Laurent Goubet [laurent.goubet@xxxxxxx] Отправлено: 1 июля 2009 г. 16:24 Кому: MDT OCL mailing list Тема: Re: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2? Hi, I'd also rather see us focus our efforts on supporting OCL 2.2 as best as can be instead of splitting the dev between the adoption of this new spec and the disambiguation/support of things that have changed since OCL 2.0. The list of changes (as in "break") between the two versions might be limited enough for us to maintain both version at small cost ... but if this list becomes too large it will rapidly become an ordeal to make changes towards the adoption of 2.2. Laurent Adolfo Sánchez-Barbudo Herrera a écrit :Relating the following bug https://bugs.eclipse.org/259031 recently replied by Ed. I'm confused. Are we going to support both specification versions in MDT-OCL 2.0.0?. I believe that it could be a chaos if we try tackle that challenge. I think that must clearly specify what are we going to do, and update the wiki with our ideas. We are 4 thinking heads who must align our thoughts in the same way... >From my point of view, we must bury OMG OCL 2.0 specification and change the implementation to adopt the new OCL 2.2 one. Keeping two implementations to support both specifications doesn't seem to be reasonable, in my opinion. If a client would like to use an OMG OCL 2.0 compliant implementation instead of the new one, he just have to use MDT OCL 1.3. What do you think? Cheers, Adolfo. -- *Adolfo Sánchez-Barbudo Herrera* adolfosbh(at)opencanarias(dot)com <mailto:adolfosbh%28at%29opencanarias%28dot%29com> C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268 ------------------------------------------------------------------------ _______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev --
|
