Hi Team,
I'm finally back from my trip....
Now, I have some time to invest on MDT-OCL. My priorities in short time
are:
1. Reading the last unread bugzillas.
2. Looking for pending patches to see if they can easily be committed.
3. Investigate why those UML2 test cases are failing.
4. Take up the LPG2 migration again.
Best regards,
Adolfo.
Ed Willink escribió:
Hi
M6 in mid-March is the API freeze, so we have 4 months left for any
changes that can be done as part of the major increment to 3.0.0.
Most of the AST/parser stuff is done; just a few trivia to align with
the final ballot resolution details; assuming that they are voted
through. Migration to LPG 2 should be pretty easy, stage one is already
+1'd subject to LPG in Orbit. Stage 2 may be almost ready for review
after resubmission.
I'm starting to look at the Environment issues; firstly to migrate the
QVT File/Root/Node environments across so that EcoreEnvironment and
UMLEnvironment don't have to be reimplemented in derived Environments
and secondly to merge the tryXXX lookups and CST lookup arguments to
have a clean preferred hierarchy of lookup methods, retaining most of
the existing methods for probable though not guaranteed compatibility.
Adolfo no doubt remembers what a mess QVTd gets into trying to override
these methods.
The role of the Environments is well-indicated by the OCL specification.
The role of the extra helper objects is not; reflection; type resolver;
type util, standard library etc. I think we want to try to have a
single reflection object owned by the root environment that provides
binding-dependent services, and a single library mode; that adds as
little functionality as possible to that provided by an EMF model.
Therefore a lot of library/resolver/type functionality may need to move
to the reflection object.
I can do the Environment changes. We need a volunteer for the
type/library changes which will need to tackle issues such as making
the standard library a first class model and making the type
inheritance model-driven. With this in place the enhancements to the
evaluator to support invalid and OclAny may become obvious.
If we don't start work on this soon we will lose the opportunity.
For the Model Registry, I am doubtful that I will have time to develop
the better GUI. However a View-based rather than Property Page-based
GUI need not be an API breaker, so this can wait. I may therefore
submit the Model Registry soon, after only a minor API review.
For the editor, there is good news. The three most annoying bugs that
provoked me to create a private bug-fixed version are fixed in CVS. The
IMP project plan shows a 1.0 release planned for Helios. To preserve
an ability to enhance editor APIs next year we might choose to bundle
the editor in the examples feature, put internal on all package names,
or just not export the packages.
Could someone please review
https://bugs.eclipse.org/bugs/show_bug.cgi?id=290654
(one week old)?
Alex: How's the Bug 293605 posting to
eclipse.org-committers doing?
Regards
Ed
_______________________________________________
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 |
|
