Re: HA: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2?

[Laurent Goubet <laurent.goubet@xxxxxxx>]

Team,

I must admit I can't totally agree with any point, be it dropping 2.0
support or supporting both 2.0 and 2.2.

On the one hand, as a commiter myself on one of the projects heavily
depending on OCL, I can't merely accept dropping 2.0 support as -as Ed
mentionned- MTL specification precisely states its dependency towards
OCL 2.0 and not "2.0 or higher". On the same issue, I just know clients
will take a long while to migrate to Galileo ... and an even longer time
to migrate towards helios even after its release; thus having them adopt
OCL 2.2 and migrate all of their legacy code from MDT-OCL 1.3 / OMG OCL
2.0 to the newer version will be but a dream until way after helios
comes by. I'm pretty sure dropping the 2.0 specification support is a
good way of seeing forks of MDT-OCL 1.3 spawn all around.

On the other hand, I do aggree that maintaining compatibility of both
specification versions will be extremely tedious if not impossible at
times. Adolfo's example of the removed metaclasses is a good example of
this : we would need to maintain both metamodel versions, both generated
code bases, both parsers, ...

All in all, I guess we will need to maintain a version of MDT-OCL
compatible with the 2.0 specification in one way or another ... We may
be able to have MDT-OCL 2.0 drop all support of the 2.0 specification
and create a 1.4 version of the plugin being more of a copy of MDT-OCL
1.3 but with just enough development to be installable under Helios?
This would force us to change this "1.4" version enough for it to be
able to cohabitate with the newer MDT-OCL 2.0 if both are to be
installed in Helios ...

Anyway, we clearly need to make a clear decision on this issue before
tackling any new development.

Laurent

Adolfo Sánchez-Barbudo Herrera a écrit :
> 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.
> -Mariano".
>
> 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
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mdt-ocl.dev mailing list
>> mdt-ocl.dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>>   
>
> -- 
>
> 	*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
>