Hi Team,
I think it's the right decision, though having the new
engine in Helios would be very tempting.
If
we're clever, we might manage to provide a separate ReflectiveLibrary add-on for
Helios. At present the ReflectiveLibrary has only very small API extensions,
these could be added with null implementations, perhaps allowing the library to
be used after all. Since the add-on would just be an entry on the update site,
it could be changed all the way to RC4 (and
beyond).
I think we shouldn't try to join the old codebase and
the one from the branch. I would rather have it as a different MDT OCL version
(experimental edition) available at a separate update site in the same manner we
wanted to do with 1.4.0. The only difference would be that there would be no
intention to make the official and the experimental versions co-exist
together.
We
therefore need to partition the outstanding bugs and only tackle those that are
independent of the move to the ReflectiveLibrary. This will be a few parser
niceties such as _'xxx'.
Regards,
- Alex.
Hi Alex
I've decided that it is just too ambitious/risky to
get this in for M6. We are sure to provoke unhappy customers. Let's try to have
it ready for M6 but not commit till M1, so that we have plenty of time to polish
before anyone sees it at M1, and even more thereafter. We may even have time to
develop an OCL_1_3_0.oclstdlib.
We therefore need to partition the
outstanding bugs and only tackle those that are independent of the move to the
ReflectiveLibrary. This will be a few parser niceties such as
_'xxx'.
Regards
Ed Willink
On 19/01/2010 18:38, Alexander Igdalov
wrote:
Hi Ed,
Although I like
very much the new approach in the reflective branch, I am not sure we should
merge it with HEAD in this release. Even if we make all tests green and provide patches for QVTO we won't have enough time to get the feedback
from our users/downstream projects to check that the new version is stable.
Since it is quite a big amount of changed
code, we (and consequently the downstream projects) are as well at risk of overlooking something while reviewing...
As you have mentioned it is challenging to get all this by
the API freeze to avoid a major increment next year, so let's see what we will
have by M5 and M6...
Regards,
- Alex.
Hi Alex
Getting all
this ready for M5/6 is certainly challenging, but unless we do a major
increment next year too, it's almost now or never. That is why I have
reorganised my plans to put as much time in before M6 as possible and to fudge
the editors etc as examples a bit later for M7 with QVTd deferred
again.
The 'phase 2' in the analyzer may merge forward into a 'phase 3'
the remaining major API activity; revising the Environments to support nested
environments in the style that QVTd parsing exploits.
Constructive
reviews, particularly of APIs will be very helpful. We cannot easily change
them later, so let's try to get them right.
Minor contributions of
tests of operations are differently helpful. Laurent has done many of these
identifying a frightening number of problems in the 1.3.0 behaviour. A fair
number of Laurent's results have changed as a result of OCL resolutions on
invalid and null. So a review of all the new GenericEvaluatxxxx tests would be
useful.
However it will be helpful to defer long philosophical
discussions about subtle invalid handling till M7/M8. Such discussions are
important but time consuming. The requisite bug fixes/OMG issues should not
affect the API framework and should be localised in a library entry or
operation class.
I do not expect QVTo to track these changes, so we
must provide a high degree of compatibility withy patches for QVTo where
compatibility is not 100%. However if Sergey likes the look of OCL.oclstdlib
and feels motivated to develop QVTo.oclstdlib immediately we could put less
effort into patches.
Regards
Ed
On 19/01/2010
14:47, Alexander Igdalov wrote:
Ed,
I could do tests/reviews. I am hoping to
have a closer look at what has to be done in the analyzer and let you
know if I could help with it in the middle of next week.
As regards the branch, I liked very much the
implementation of the model-driven library approach you did there. However,
I am not sure it can substitute the old codebase in Helios. Even if it
becomes stable before M6 (API freeze) we should remember about our
downstream projects... I wouldn't merge it with HEAD after M5 unless we
provide patches for QVTO, etc...
Ed, how would you estimate the time needed to make
the branch stable (by 'stable' I mean a stable interim state, e.g. with
phase1 only)? Moreover, do you think it makes sense to have a
stable but a logically unfinished engine in this
release with pending breaking changes in the next
release?
Regards,
- Alex.
Hi Alex
Yes. In so far as possible
everything that could be defined by an XXX.oclstdlib should be, so that just
by changing to YYY.oclstdlib you get a different configuration of behaviour.
The most important change is for lookup to search the generic library rather
than the Ecore/UML library.
Everything in the analysis field is part
of 'phase 2' though I'm beginning to suspect that 'phase 1' may stall
without doing 'phase 2' anyway since 'def' constraints must be added to the
library by the analyzer.
How much time do you have
available?
Small amounts of time could help with
tests/reviews.
More substantial time could help with perhaps 'phase
2'.
Beware: the branch is my development area. It is not equivalent
in quality to committed code. There is much still to
do.
Ed
On 19/01/2010 13:41,
Alexander Igdalov wrote:
Hi Ed,
Thanks for informing me.
I am now merging my patch for collections conformance to OclAny with the
Reflective Library branch. As I see it, there is conformance information in
the OCL.oclstdlib file, i.e. it is mentioned there that Collections conform
to OclAny. Still this information is not used in
AbstractTypeChecker.getRelationShip() and etc. Are you planning to update
the type checker so that it would use the library model rather than perform
by-hand conformance resolution like in getRelationship methods?
Cheers,
- Alex.
-----Original Message-----
From: Ed Willink [mailto:ed@xxxxxxxxxxxxx]
Sent: Tuesday, January 19, 2010 4:23 PM
To: Alexander Igdalov
Subject: Reflective Library progress
Hi Alex
The UML tests now 'work' as well; 116 failures rather than 400.
I've added Status.txt at the foot of o.e.o to remind myself (tell you) what
needs to be done.
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 270.14.150/2632 - Release Date: 01/19/10 07:34:00
|