I have a meta model defined in Ecore which models concepts similar to
those in UML, e.g. Class, Property, Association, Genralization, and also
State machines. The concepts are pretty much "copied" from UML.

I would now like to add OCL support, so that users can add OCL
constraints to their model. In fact, users already do add constraints to
their model by instatiating a "Constraint" metaclass that has a simple
EString feature, currently just uninterpreded text. There are also some
additional EStructuralFeatures typed with EString that serve a similar
purpose.

I understand that for us, evaluation is not really an issue because
there are no instances on which to evaluate, so we'd need only parsing
plus code-completion/syntax highlighting.

Do I see it correctly that I have now the choice between:

A. Extend org.eclipse.ocl.AbstractEnvironmentFactory (The one with the
many type parameters), orienting myself on UMLEnvironmentFactory.

B. Use the pivot binding. In principle, I would like to pursue that
approach because the documentation promotes it as the 'future stuff'. Is
that still the case? The problem is that I don't really see what I'd
have to do. Is the pivot binding made so I can plug-in my own
Metamodel-to-Pivot transformation? Or do I just take the example and
modify it to suit my needs?

I also have a question on Eclipse OCL dependencies. For this new project
we will use the 3.8.2 Platform with EMF 2.8. Eclipse OCL installed fine
from the Juno repository, but what about future releases? If OCL makes
improvements, say in Kepler, or even further ahead would I be able to go
with the new OCL versions, while staying on the 3.8.2 Platform with EMF 2.8?

You might find that you can achierve what you want by enhancing the
OCLinEcore grammar towards what I have the UnifiedOCL grammar; the pivot
model already has statemachines so you might not find it that hard.

The OCL with Xtext support is tightly coupled to Xtext, but you should
find that it all upgrades ok on 3.8.2.

Regards

Ed Willink

On 21/02/2014 09:08, Felix Dorner wrote:
> Hi,
>
> I have a meta model defined in Ecore which models concepts similar to
> those in UML, e.g. Class, Property, Association, Genralization, and
> also State machines. The concepts are pretty much "copied" from UML.
>
> I would now like to add OCL support, so that users can add OCL
> constraints to their model. In fact, users already do add constraints
> to their model by instatiating a "Constraint" metaclass that has a
> simple EString feature, currently just uninterpreded text. There are
> also some additional EStructuralFeatures typed with EString that serve
> a similar purpose.
>
> I understand that for us, evaluation is not really an issue because
> there are no instances on which to evaluate, so we'd need only parsing
> plus code-completion/syntax highlighting.
>
> Do I see it correctly that I have now the choice between:
>
> A. Extend org.eclipse.ocl.AbstractEnvironmentFactory (The one with the
> many type parameters), orienting myself on UMLEnvironmentFactory.
>
> B. Use the pivot binding. In principle, I would like to pursue that
> approach because the documentation promotes it as the 'future stuff'.
> Is that still the case? The problem is that I don't really see what
> I'd have to do. Is the pivot binding made so I can plug-in my own
> Metamodel-to-Pivot transformation? Or do I just take the example and
> modify it to suit my needs?
>
>
> I also have a question on Eclipse OCL dependencies. For this new
> project we will use the 3.8.2 Platform with EMF 2.8. Eclipse OCL
> installed fine from the Juno repository, but what about future
> releases? If OCL makes improvements, say in Kepler, or even further
> ahead would I be able to go with the new OCL versions, while staying
> on the 3.8.2 Platform with EMF 2.8?
>
>
> Thanks for comments,
> Felix

> You might find that you can achierve what you want by enhancing the
> OCLinEcore grammar towards what I have the UnifiedOCL grammar;

I don't understand that sentence :). I tried to read myself through how
the Xtext OCL console does stuff, but from there it's not really clear
on how to proceed, and my head hurts. My guts feeling is that the idea
of the example API is to simply add a MetamodelManager.Factory for our
custom metamodel. The metamodel manager then picks that factory when a
pivot representation of a user model is needed. Is this more or less
correct?

I have seen that the factory for UML is reusing the one for Ecore. First
UML is transformed to Ecore and then Ecore to Pivot. This sounds
pragmatic, but won't state machines be lost?

I feel that we want similar functionality to what's available in
Papyrus, but bound against our own metamodel instead UML, and that's
just EssentialOCL afaiu.

On 27/02/2014 16:01, Felix Dorner wrote:
>
> I have seen that the factory for UML is reusing the one for Ecore.
> First UML is transformed to Ecore and then Ecore to Pivot. This sounds
> pragmatic, but won't state machines be lost?
>
That's the way it used to happen and yes things got lost.

There is now a direct UML2Pivot, currently with real StateMachine
classes. It is undesirable to replicate every UML class in the Pivot
model so obscure ones use a delegating DynamicElement. I may well throw
out Statemachines and do them dynamically too.

Any patches so far back would need to be backed by substantial funding
since supporting legacy releases is not an Open Source activity.

You might be better off creating a GitHub fork so that your
contributions are recorded and available.

For the Classic OCL plugins where not much changes you could just
backport the newer code.

For the Pivot OCL there has been substantial progress so the fixes are
pretty pointless.

Regards

Ed Willink

On 03/03/2014 12:36, Felix Dorner wrote:
> Hi Ed.
>
> On 03/03/2014 12:36, Ed Willink wrote:
>
>> I'm afraid you have to be joking.
>
> I was pretty sure about the answer, yet I had to ask.
>
>> Firstly, I struggle to provide the current development ... largely
>> unpaid.
>
> Ok. Not sure how I could help. I will at least try use the pivot model
> (Currently advancing on the converter) and maybe give feedback on the
> API and at least report bugs and weird stuff I find.
>
>> Secondly, I am afraid I have little respect for such local authorities
>> who impose draconian Eclipse usage limits yet fail to contribute
>> financially to projects they exploit.
>
> I could probably send patches based on Juno for bugs that I have to
> fix myself. I still need to ask the client though, and hope that there
> aren't too many ;)
>
>
> Would you yet kindly confirm which git branch the Juno release is
> based on?
>
> Thanks and sorry for the upset.
> Felix

> You might be better off creating a GitHub fork so that your
> contributions are recorded and available.

I found that I had no other way to try to backport OCL to XText
2.3/Juno. I started off with the master branch (If I start a backport,
why not from the bloody edge..)

I only had to touch the following:

- Xtext grammar models are stored in xtextbin, binary resources, which
isn't supported in Xtext 2.3. I simply converted them to xmi.

- There @Nullable and @NotNull annotations on fields were introduced in
Kepler or later, so there were a lot of compiler errors. I simply
commented them out. This is compile time only, so it's not even strictly
needed..

Running org.eclipse.ocl.examples.test.xtext.AllXtextTests makes me
confident that it actually works. I have 7 Errors, but I also had them
when I run the TestSuite against XText 2.4.

I don't know if you know of anything else that might be worthwile for me
to test/check.

I hadn't appreciated that you were prepared to regenerate. I assumed
that you wanted to use the old code and bug fix it. I doubt that
anything from Xtext > 2.3 is in use. So the backport should be easy.

If you look in the ...build plugin you will find scripts rto generate
e.g. AllEditors. So just regenerate.

Regards

Ed Willink

On 06/03/2014 18:38, Felix Dorner wrote:
> Hi Ed,
>
>> You might be better off creating a GitHub fork so that your
>> contributions are recorded and available.
>
>
> I found that I had no other way to try to backport OCL to XText
> 2.3/Juno. I started off with the master branch (If I start a backport,
> why not from the bloody edge..)
>
> I only had to touch the following:
>
> - Xtext grammar models are stored in xtextbin, binary resources, which
> isn't supported in Xtext 2.3. I simply converted them to xmi.
>
> - There @Nullable and @NotNull annotations on fields were introduced
> in Kepler or later, so there were a lot of compiler errors. I simply
> commented them out. This is compile time only, so it's not even
> strictly needed..
>
> Running org.eclipse.ocl.examples.test.xtext.AllXtextTests makes me
> confident that it actually works. I have 7 Errors, but I also had them
> when I run the TestSuite against XText 2.4.
>
> I don't know if you know of anything else that might be worthwile for
> me to test/check.
>
>
> Cheers,
> Felix

On 06/03/2014 21:48, Ed Willink wrote:
> Hi
>
> I hadn't appreciated that you were prepared to regenerate. I assumed
> that you wanted to use the old code and bug fix it. I doubt that
> anything from Xtext > 2.3 is in use. So the backport should be easy.

Do you think that it might be possible to reintegrate such a backport
into the OCL repo and make a build available through the juno update
site? I'd be more than willing to help out.

My preferred solution would be to discover the Xtext 2.6/2.3
incompatibilities and either avoid them or introduce some compatibility
helpers. The main release would then be useable as is without the need
for variants. But not knowing what the incompatibilities are I cannot
tell whether they are trivial or impossible.

If you produce a patch/GitHub branch for the Luna_M6 tag that makes it
useable for you, I can review what is involved. NB Please do no other
changes since I don't like being confused by extraneous changes.

Regards

Ed Willink

On 13/03/2014 11:51, Felix Dorner wrote:
> On 06/03/2014 21:48, Ed Willink wrote:
>> Hi
>>
>> I hadn't appreciated that you were prepared to regenerate. I assumed
>> that you wanted to use the old code and bug fix it. I doubt that
>> anything from Xtext > 2.3 is in use. So the backport should be easy.
>
> Do you think that it might be possible to reintegrate such a backport
> into the OCL repo and make a build available through the juno update
> site? I'd be more than willing to help out.
>
> Felix
>

I have made sufficient progress to be relatively confident that there
will be support for an OCL Debugger in Luna (but for Pivot only).

Regards

Ed Willink

On 14/03/2014 12:51, Felix Dorner wrote:
> On 14/03/2014 12:11, Ralph Gerbig wrote:
>
>> we did the same as you and Chose Option A. This works fine for us so
>> far.
>
> My heart says Pivot, my Head says Option A, and when I dream at night
> I'm doing both :). Thanks for the feedback.
>
> Felix

On 15/03/2014 11:32, Ed Willink wrote:
> If you produce a patch/GitHub branch for the Luna_M6 tag that makes it
> useable for you, I can review what is involved. NB Please do no other
> changes since I don't like being confused by extraneous changes.

I had to add jdt.annotations to the development classpath for some of
the bundles. (I found that one of the Xtext 2.4 bundle reexports this
dependency while Xtext 2.3 doesnt.

I have also run the 'Generate All Editors' workflow and committed the
significant changes. I don't know if there are any other components that
would need to be regenerated to see differences for the two targets. I
saw that the genmodels runtime target is always EMF 2.7, so that should
be fine. Do you intend to bump this? EMF 2.8 would be maximum for me.

I have some compilation errors in examples.build. I'm not sure these
matter at all (The bundle is only used for build/releng right?), but I
list them here anyways:

- The jet "Class" template makes use of some EMF 2.9 genmodel features
- GenmodelReloader, IdAssigner, ResourceWriter use a resource save
option which also seems to be EMF 2.9: OPTION_LINE_DELIMITER
- I use Kepler for development, and there seems to be no way to tell the
Xtext compiler that the Xtend files in build.extend target an Xtend 2.3
runtime (I asked in the TMF forum, but no reply so far..)

The most prolific change: manifest bounds can easily be accomodated on
the main development branch since you are demonstrating that we can
widen Xtext to [2.3.1,3.0.0).

Some other changes such as XMI/XtextBin we can happily have both.

jdt.annotations is a compile time only facility; it should only be on
the additional compile classpath (build.properties), so at run-time you
don't need it/use it.

Now that you've demonstrated that a backport is possible, would you like
to see if you/we can just lower lower bounds etc so that the Luna M7
code can be more useable for you?

[Yes the build plugin is for releng only, which makes it easier to fix
in some ways.]

You are welcome to do an Oomph. I don't know of any other attempt. If
it's useful and appropriate, the OCL project can host it.

Regards

Ed

On 18/03/2014 13:26, Felix Dorner wrote:
> Hi Ed,
>
> On 15/03/2014 11:32, Ed Willink wrote:
>> If you produce a patch/GitHub branch for the Luna_M6 tag that makes it
>> useable for you, I can review what is involved. NB Please do no other
>> changes since I don't like being confused by extraneous changes.
>
> I have pushed a branch that's based of Luna_M6 to
>
> https://github.com/soyatec/ocl/tree/soyatec/luna_backport
>
> You can compare it against Luna_M6 here:
>
> https://github.com/soyatec/ocl/compare/eclipse:Luna_M6...soyatec%2Fluna_backport
>
>
> I had to add jdt.annotations to the development classpath for some of
> the bundles. (I found that one of the Xtext 2.4 bundle reexports this
> dependency while Xtext 2.3 doesnt.
>
> I have also run the 'Generate All Editors' workflow and committed the
> significant changes. I don't know if there are any other components
> that would need to be regenerated to see differences for the two
> targets. I saw that the genmodels runtime target is always EMF 2.7, so
> that should be fine. Do you intend to bump this? EMF 2.8 would be
> maximum for me.
>
> I have some compilation errors in examples.build. I'm not sure these
> matter at all (The bundle is only used for build/releng right?), but I
> list them here anyways:
>
> - The jet "Class" template makes use of some EMF 2.9 genmodel features
> - GenmodelReloader, IdAssigner, ResourceWriter use a resource save
> option which also seems to be EMF 2.9: OPTION_LINE_DELIMITER
> - I use Kepler for development, and there seems to be no way to tell
> the Xtext compiler that the Xtend files in build.extend target an
> Xtend 2.3 runtime (I asked in the TMF forum, but no reply so far..)
>
>
> Btw, I would like to author an Oomph setup model
> (https://wiki.eclipse.org/Eclipse_Oomph_Installer) for the OCL
> component, wanted to ask if you or anyone has maybe already tried?
>
>
> Felix
>
>

> The most prolific change: manifest bounds can easily be accomodated on
> the main development branch since you are demonstrating that we can
> widen Xtext to [2.3.1,3.0.0).

Yes.

> Some other changes such as XMI/XtextBin we can happily have both.

Yes, but the generated code must be modified (or the generation must use
a different template, I know little about Xtext, not sure).

> Now that you've demonstrated that a backport is possible, would you like
> to see if you/we can just lower lower bounds etc so that the Luna M7
> code can be more useable for you?

Lower the bounds and solve the XtextBin issue. The other
incompatibilities are the wizards and the validity example. Would be
nice to have the wizards work :) Not sure how important the "Bidi"
support is for you. I think I don't care if Validity works or not, and
the ValidateHandler isn't an issue either.

The @NonNull problems go away if the JDT Beta patch is installed and a
missing @NonNull dependency is added..

The Bidi problems are easily fixed. Just delete the code.
Internationalization support is pretty dubious for OCL anyway.

Changing bounds to Xtext 2.3.1 and nearly all problems are gone.

The new validation plugins dependent on EMF 2.9 can be fixed; disable
for now.

All the above could be fixed in the main code.

That just leaves the XtextBin/XMI issue.

Modifying the editor build scripts to specify

fragment = grammarAccess.GrammarAccessFragment
{xmlVersion="1.1"}

gets XMI files that can be back copied. Then deleting the BinaryResource
factories and we are error free.

Unfortunately trying to run the editors gives a Guice provision error,
nominally on a bad null Package URI, but with a completely stupid
grammar XMI line number. On further investigation it is because the SAX
parser thinks it has tokenized " <elements x" as the xsi:type. I
suspect that the EMF encoding of { or ( or = has evolved, or perhaps the
XML preamble is wrong.

This might be trivial or might be a killer, but it is kind of
encouraging that we can get this far. I am afraid I do not have time to
investigate further.

-----------------------

If you can find the problem, I think there may be a way forward.

Using a custom derived grammarAccess.GrammarAccessFragment we can either:

a) generate both XMI and XtextBin grammars with a smart derived derived
BinaryResource to do nothing on Xtext 2.3.1

b) generate just XtextBin grammar but provide a smart 'derived'
BinaryResource that works on both Xtext 2.3.1 and ... 2.6

------------------------

However while we may have got past the compiler-mediated API
compatibility, the SAX parser problem may be just the first of many
semantic API incompatibilities.

In the early 2.x days the Xtext behavior was changing quite a lot. It is
more stable now, but we could easily find that a backport collapses with
Xtext 2.7.

Is it really worthwhile? I'm not entirely clear about the use case that
allows a future OCL but not a future Xtext.

Regards

Ed Willink

On 18/03/2014 18:51, Felix Dorner wrote:
> On 18/03/2014 18:12, Ed Willink wrote:
>> Hi Felix
>>
>> The changes look remarkably small.
>
> Yes it's not much.
>
>> The most prolific change: manifest bounds can easily be accomodated on
>> the main development branch since you are demonstrating that we can
>> widen Xtext to [2.3.1,3.0.0).
>
> Yes.
>
>> Some other changes such as XMI/XtextBin we can happily have both.
>
> Yes, but the generated code must be modified (or the generation must
> use a different template, I know little about Xtext, not sure).
>
>> Now that you've demonstrated that a backport is possible, would you like
>> to see if you/we can just lower lower bounds etc so that the Luna M7
>> code can be more useable for you?
>
> Lower the bounds and solve the XtextBin issue. The other
> incompatibilities are the wizards and the validity example. Would be
> nice to have the wizards work :) Not sure how important the "Bidi"
> support is for you. I think I don't care if Validity works or not, and
> the ValidateHandler isn't an issue either.
>
>
>
>
> Cheers,
> Felix

I will check. I don't know if it's worthwile. It's surely a PITA to
spend time on that stuff rather than just focusing on the real work.
Felix

On 19/03/2014 08:58, Ed Willink wrote:
> Hi
>
> I tried loading the current code on an Eclipse 4.2.2 platform:
>
> The @NonNull problems go away if the JDT Beta patch is installed and a
> missing @NonNull dependency is added..
>
> The Bidi problems are easily fixed. Just delete the code.
> Internationalization support is pretty dubious for OCL anyway.
>
> Changing bounds to Xtext 2.3.1 and nearly all problems are gone.
>
> The new validation plugins dependent on EMF 2.9 can be fixed; disable
> for now.
>
> All the above could be fixed in the main code.
>
> That just leaves the XtextBin/XMI issue.
>
> Modifying the editor build scripts to specify
>
> fragment = grammarAccess.GrammarAccessFragment
> {xmlVersion="1.1"}
>
> gets XMI files that can be back copied. Then deleting the BinaryResource
> factories and we are error free.
>
> Unfortunately trying to run the editors gives a Guice provision error,
> nominally on a bad null Package URI, but with a completely stupid
> grammar XMI line number. On further investigation it is because the SAX
> parser thinks it has tokenized " <elements x" as the xsi:type. I
> suspect that the EMF encoding of { or ( or = has evolved, or perhaps the
> XML preamble is wrong.
>
> This might be trivial or might be a killer, but it is kind of
> encouraging that we can get this far. I am afraid I do not have time to
> investigate further.
>
> -----------------------
>
> If you can find the problem, I think there may be a way forward.
>
> Using a custom derived grammarAccess.GrammarAccessFragment we can either:
>
> a) generate both XMI and XtextBin grammars with a smart derived derived
> BinaryResource to do nothing on Xtext 2.3.1
>
> b) generate just XtextBin grammar but provide a smart 'derived'
> BinaryResource that works on both Xtext 2.3.1 and ... 2.6
>
> ------------------------
>
> However while we may have got past the compiler-mediated API
> compatibility, the SAX parser problem may be just the first of many
> semantic API incompatibilities.
>
> In the early 2.x days the Xtext behavior was changing quite a lot. It is
> more stable now, but we could easily find that a backport collapses with
> Xtext 2.7.
>
> Is it really worthwhile? I'm not entirely clear about the use case that
> allows a future OCL but not a future Xtext.
>
> Regards
>
> Ed Willink
>
>
>
>
>
>
>
> On 18/03/2014 18:51, Felix Dorner wrote:
>> On 18/03/2014 18:12, Ed Willink wrote:
>>> Hi Felix
>>>
>>> The changes look remarkably small.
>>
>> Yes it's not much.
>>
>>> The most prolific change: manifest bounds can easily be accomodated on
>>> the main development branch since you are demonstrating that we can
>>> widen Xtext to [2.3.1,3.0.0).
>>
>> Yes.
>>
>>> Some other changes such as XMI/XtextBin we can happily have both.
>>
>> Yes, but the generated code must be modified (or the generation must
>> use a different template, I know little about Xtext, not sure).
>>
>>> Now that you've demonstrated that a backport is possible, would you like
>>> to see if you/we can just lower lower bounds etc so that the Luna M7
>>> code can be more useable for you?
>>
>> Lower the bounds and solve the XtextBin issue. The other
>> incompatibilities are the wizards and the validity example. Would be
>> nice to have the wizards work :) Not sure how important the "Bidi"
>> support is for you. I think I don't care if Validity works or not, and
>> the ValidateHandler isn't an issue either.
>>
>>
>>
>>
>> Cheers,
>> Felix
>

> That just leaves the XtextBin/XMI issue.
>
> Modifying the editor build scripts to specify
>
> fragment = grammarAccess.GrammarAccessFragment
> {xmlVersion="1.1"}
>
> gets XMI files that can be back copied. Then deleting the BinaryResource
> factories and we are error free.
>
> Unfortunately trying to run the editors gives a Guice provision error,
> nominally on a bad null Package URI, but with a completely stupid
> grammar XMI line number. On further investigation it is because the SAX
> parser thinks it has tokenized " <elements x" as the xsi:type. I
> suspect that the EMF encoding of { or ( or = has evolved, or perhaps the
> XML preamble is wrong.

The XML 1.1 is there described as a workaround, and a user who tried it
got exactly the same guice injector errors that you describe. What I did
instead is:

Convert the binary resources to xmi, but leaving the originals in place.
To convert I used the reflective Ecore Editor, it treats the .xtextbin
files nicely.

The only thing left was to remove the missing class compiler error by
changing the *StandaloneSetup files to use a copy of the
BinaryXtextResourceFactory which I added to ocl.xtext.base.utils.

I confirm via debugging and by looking at the Xtext code (See
org.eclipse.xtext.service.GrammarProvider)
that with this setup the Xtext 2.4 runtime will use the .xtextbin file,
and the Xtext 2.3 runtime will use the .xmi file. This is great because
for the "Official" target the patch has almost no side effects (Except
that it now uses the copied resource factory)

I presume you mean BinaryGrammarResourceFactoryImpl rather than
BinaryXtextResourceFactory. Using this there is no need for the XMIs,
just a small change to the grammarAccess.GrammarAccessFragment to
reference the changed class name. Then the Luna build for Xtext 2.6 can
run without change on Juno with Xtext 2.3.1.

If an Xtext back-port is really so easy, we might try to persuade itemis
to autogenerate BinaryGrammarResourceFactoryImpl into the editor so that
all editors are back-portable without a
grammarAccess.GrammarAccessFragment customization.

Regards

Ed Willink

On 19/03/2014 15:55, Felix Dorner wrote:
> On 19/03/2014 08:58, Ed Willink wrote:
>
>> That just leaves the XtextBin/XMI issue.
>>
>> Modifying the editor build scripts to specify
>>
>> fragment = grammarAccess.GrammarAccessFragment
>> {xmlVersion="1.1"}
>>
>> gets XMI files that can be back copied. Then deleting the BinaryResource
>> factories and we are error free.
>>
>> Unfortunately trying to run the editors gives a Guice provision error,
>> nominally on a bad null Package URI, but with a completely stupid
>> grammar XMI line number. On further investigation it is because the SAX
>> parser thinks it has tokenized " <elements x" as the xsi:type. I
>> suspect that the EMF encoding of { or ( or = has evolved, or perhaps the
>> XML preamble is wrong.
>
> The origin for the binary resource technique is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=327080
>
> The XML 1.1 is there described as a workaround, and a user who tried
> it got exactly the same guice injector errors that you describe. What
> I did instead is:
>
> Convert the binary resources to xmi, but leaving the originals in
> place. To convert I used the reflective Ecore Editor, it treats the
> .xtextbin files nicely.
>
> The only thing left was to remove the missing class compiler error by
> changing the *StandaloneSetup files to use a copy of the
> BinaryXtextResourceFactory which I added to ocl.xtext.base.utils.
>
> I confirm via debugging and by looking at the Xtext code (See
> org.eclipse.xtext.service.GrammarProvider)
> that with this setup the Xtext 2.4 runtime will use the .xtextbin
> file, and the Xtext 2.3 runtime will use the .xmi file. This is great
> because for the "Official" target the patch has almost no side effects
> (Except that it now uses the copied resource factory)
>
> Instead of further modifying the existing branch I started from
> scratch and pushed it to
> https://github.com/soyatec/ocl/tree/soyatec/luna_backport2
>
> The relevant commit is:
>
> https://github.com/soyatec/ocl/commit/1b3d51e39bf4e19de011626610d560484aea38e4
>
>
>
>

Yes. I open the RoyalAndLoyal example in the CompleteOCL editor. I
edited a bit too, just a bit. Also: I run
org.eclipse.ocl.examples.test.xtext.AllXtextTests

which includes some tests that loads editors and tests the console.

> It seems like you've solved the Guice/XMI/SAX problem.
> I presume you mean BinaryGrammarResourceFactoryImpl rather than
> BinaryXtextResourceFactory.

Yeah, sorry. Sometimes I just make names up :(

> Using this there is no need for the XMIs,
> just a small change to the grammarAccess.GrammarAccessFragment to
> reference the changed class name. Then the Luna build for Xtext 2.6 can
> run without change on Juno with Xtext 2.3.1.

I just looked at their code to see that the Xtext 2.3 runtime will only
look for .xmis, no matter what changes you make to generated code.

The Xtext 2.4 runtime will look for xtextbin and if that fails for xmi.

I don't understand a lot about Xtext, but I can't see how just changing
the grammarAcces.GrammarAccessFragment will remove the need to package
the .xmi files?

> If an Xtext back-port is really so easy, we might try to persuade itemis
> to autogenerate BinaryGrammarResourceFactoryImpl into the editor so that
> all editors are back-portable without a
> grammarAccess.GrammarAccessFragment customization.

That would have been a good thing from the beginning. EMF generates a
ResourceFactory for every model, so why wouldn't Xtext want to do the same?

>> If an Xtext back-port is really so easy, we might try to persuade itemis
>> to autogenerate BinaryGrammarResourceFactoryImpl into the editor so that
>> all editors are back-portable without a
>> grammarAccess.GrammarAccessFragment customization.
>
> That would have been a good thing from the beginning. EMF generates a
> ResourceFactory for every model, so why wouldn't Xtext want to do the same?
>
> I will file a bug for Xtext.

On Xtext 2.3.1 only *.xmi grammars are read so any *.xtextbin
registrations are pointless.

Regards

Ed Willink

On 20/03/2014 17:17, Felix Dorner wrote:
> On 20/03/2014 09:39, Felix Dorner wrote:
>
>>> If an Xtext back-port is really so easy, we might try to persuade
>>> itemis
>>> to autogenerate BinaryGrammarResourceFactoryImpl into the editor so
>>> that
>>> all editors are back-portable without a
>>> grammarAccess.GrammarAccessFragment customization.
>>
>> That would have been a good thing from the beginning. EMF generates a
>> ResourceFactory for every model, so why wouldn't Xtext want to do the
>> same?
>>
>> I will file a bug for Xtext.
>
> I'm not a good persuador :_(
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=430776
>
>

By introducing a CompatibilityGrammarProvider on Xtext 2.3.1 the
*.xtextbin grammars can be used enabling the unmodified Luna OCL
distribution generated with Xtext 2.6 to be run on Juno.

The only cost is two extra classes and a trivial one-time degradation to
grammar access/standalone setup.

I'm able to run all tests with 3 standalone failures (UML2 support has
improved) and 11 plugin failures (GenModel has improved).

Just need to sort out the Bidi/Validate compatibility and it could be on
master today.

Regards

Ed Willink

On 21/03/2014 08:06, Felix Dorner wrote:
> On 20/03/2014 21:10, Ed Willink wrote:
>> On Xtext 2.3.1 only *.xmi grammars are read so any *.xtextbin
>> registrations are pointless.
>
> With this patch
>
> On Xtext 2.4: The xtextbin grammar is used
> On Xtext 2.3: The xmi grammar is used.
>
> So it's not entirely pointless. If I didn't register xtextbin at all,
> 2.4 would also use xmi which I want to avoid.
>

On 21/03/2014 09:46, Ed Willink wrote:
> Hi
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=430855
>
> By introducing a CompatibilityGrammarProvider on Xtext 2.3.1 the
> *.xtextbin grammars can be used enabling the unmodified Luna OCL
> distribution generated with Xtext 2.6 to be run on Juno.
>
> The only cost is two extra classes and a trivial one-time degradation to
> grammar access/standalone setup.
>
> I'm able to run all tests with 3 standalone failures (UML2 support has
> improved) and 11 plugin failures (GenModel has improved).
>
> Just need to sort out the Bidi/Validate compatibility and it could be on
> master today.

That sounds awesome! I hope I can give something back soon. There's
these two that I'm interested in solving: