Hi Team,
I'll start some vacation time. I'll be off around one week. My
priorities when I come back are the following:
Properly fullfill and complete the API changes arisen from the new
specification. If you want to change the format or whatever. Feel free
to do it.:
http://wiki.eclipse.org/MDT/OCL/OCL_2.0_API_Changes
And this one:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=242153
I guess that it's worthy adopting LPG2, regardless how many grammars
are we going to keep >.<
P.S: Sorry for not being able to follow the discussion, I hope you get
a consent about it. From my point of view, I guess the easiest solution
is the Laurent's one (shipping different components for both
specifications, in the same fashion it's done inside OCL), although I'm
not sure if this fits in Eclipse's policies. Maybe, we could get some
advice from Kenn, PMC or whoever.
Cheers,
Adolfo.
ed@xxxxxxxxxxxxxxxxxx escribió:
Hi Adolfo
You're right. It's not easy. Code decisions can be handled by alternate
behavioiural objects/methods. The meta-models are harder.
The UML2 project gives us some clues. It supports UML 2.1 and 3.0.
The model directory contains uml.ecore (3.0) and uml_21.ecore (2.1).
The Jasva classes are from the 3.0 model only.
The important point is that the Ecore model is an Eclipse implementation
that matches the OMG/EMOF specs as closely as possible. It is not precise.
Use of EReference makes the model instantly non-identical from a pedantic
semantic viewpoint and totally incompatible from a meta-model spelling
viewpoint.
We therefore maintain the Ecore OCL 2.2 model as a slight superset
(include the obsolete classes) so that all the model classes still have
Java classes, but exclude the spurious classes programatically. Certain
reflective actions will be inaccurate, such as what are my superclasses,
but they were in accurate anyway because they had OCL class names twice
and higher level classes with E prefixes.
So for instance the TypeTypeImpl constructor when configured for OCL 2.2
must throw a ClassNotFoundException, but work normally for OCL 2.0.
Regards
Ed Willink
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
_______________________________________________
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
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
