Hi Kenn
Ok, so we do 3.0.1 and 3.0.2 to directly accompany Helios SR1 and SR2.
(Since 3.1.0 below will be available at about the same time as 3.0.1,
we will strongly encourage users to go for 3.1.0).
We advance CVS HEAD to 3.1.0 after Helios and work API compatibly in
the examples plugins till perhaps M4 when we release 3.1.0.
At M4 we advance CVS HEAD to 4.0.0 and graduate the examples plugins to
non-examples.
Ed
On 02/06/2010 16:28, Kenn Hussey wrote:
Hmm. You can't add new functionality in a maintenance
release. Although the OCL to Java generator does sounds really
useful/desirable.
Note that OCL can have major and minor releases as often as it
likes, possible out of sync with the official release train. Why not
add this new functionality in HEAD as part of a new release that ships
when you want it to?
Kenn
On Tue, Jun 1, 2010 at 2:26 AM, Ed Willink <ed@xxxxxxxxxxxxx>
wrote:
Hi
[Kenn: You might have to -1 the proposal below.]
While writing the OCLinEcore tutorial, I have been pleased by how much
fits together, and fixed one trivial drop-off; we needed a Create
Dynamic Instance within the text editor.
There are two major problems and one annoyance from a usage perspective.
a) Bug 315034; a loaded model is not valid after its meta-model is
changed (not even if the change was just a debugged invariant). This
gives major pain (NPE, CCE, IAE and worse) in the OCL Interpreter and
Sample Reflective Ecore Editor Properties View. We need to contribute a
meta-model reloader to EMF (a proxy resolver for all eClass references).
b) The editor has no Well-Formedness Validation. So any simple
collection type errors go undetected and just give a mysterious nothing
or OclInvalid in the console.
c) There is no mechanism to load a CompleteOCL document into the OCL
Interpreter.
a) and c) are simple isolated developments
b) sensibly drops out as part of the progression to a clean reflective
pivot model supporting the model-driven standard library.
I don't want users to have to wait a year for editor validation. How
can this be done in a maintenance release?
Well-formedness constraints are (or should be) cut-and-paste equivalent
to the OCL specification. We now have the technology to integrate these
in our models, so there is no need for custom Java, except that
instinctively, I cannot contemplate running interpreted OCL queries
during compilation of big meta-models.
----
Proposal; rather than doing Java generation one day, let's do it now
and use it ourselves.
Step 1: Develop an OCL to equivalent Java code generator - very little
optimisation, BigInteger, BigDecimal throughout but inline Java rather
than deep interpreter call trees.
Step 2: Enrich our meta-models with this OCL-derived Java.
Step 3: Use the enriched pivot models to provide validation in the
editor.
----
Practicalities; in order to ship this in 3.0.1
-- I continue to do everything in the examples plugins. Only
maintenance changes to non examples.
-- At about M4, we graduate the examples plugins to non-examples after
a significant review by all committers. CVS HEAD changes from 3.0.1 to
4.0.0.
-- During M4-M6 we migrate the LPG parser and analyzer to align with
the Xtext and ANTLr tooling recognising QVTo as our API compatibility
referee. Long term I think we need a major rethink of the LPG Analyzer
'protected' API, but we need to make the Xtext/Library/Generation
facilities so much better in 4.0.0 that QVTo changes from choice and
with assistance rather than compulsion in Indigo+1.
----
One day, perhaps gradually, we add optimisation to the Java generation.
Regards
Ed Willink
_______________________________________________
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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2913 - Release Date: 06/02/10 10:57:00
|
