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
|