Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL binding for UML-like metamodel
OCL binding for UML-like metamodel [message #1252486] Fri, 21 February 2014 09:08 Go to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1254671 is a reply to message #1252486] Sun, 23 February 2014 17:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Your hitting three of four things on my TODO list.

The pivot binding is definitely future stuff prototyping ideas for OCL 2.5.

Using Classic OCL is not an option if you want an Xtext editor.

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
Re: OCL binding for UML-like metamodel [message #1258658 is a reply to message #1254671] Thu, 27 February 2014 16:01 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hi Ed,

On 23/02/2014 18:30, Ed Willink wrote:

> Your hitting three of four things on my TODO list.

Nice.

> 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.


Felix
Re: OCL binding for UML-like metamodel [message #1258666 is a reply to message #1258658] Thu, 27 February 2014 16:14 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

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.

If you just use

MetaModelManager.loadResource(@NonNull Resource resource, @Nullable URI
uri) throws ParserException

it should use the appropriate xxx to pivot automatically.

I think that is what Papyrus uses.

Regards

Ed Willink
Re: OCL binding for UML-like metamodel [message #1262211 is a reply to message #1254671] Mon, 03 March 2014 11:25 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hey,

On 23/02/2014 18:30, Ed Willink wrote:
> The OCL with Xtext support is tightly coupled to Xtext, but you should
> find that it all upgrades ok on 3.8.2.

the local authorities prevent me from upgrading beyond XText 2.3, i.e.
the Juno release. Thus I cannot upgrade OCL either.

Does the OCL (Pivot Model, EssentialOCL grammar and StdLib) Juno release
receive bugfixes?

Which is the branch for the Juno release in git?

Thanks,
Felix
Re: OCL binding for UML-like metamodel [message #1262219 is a reply to message #1262211] Mon, 03 March 2014 11:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I'm afraid you have to be joking.

Firstly, I struggle to provide the current development ... largely unpaid.

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.

Regards

Ed Willink

On 03/03/2014 11:25, Felix Dorner wrote:
> Hey,
>
> On 23/02/2014 18:30, Ed Willink wrote:
> > The OCL with Xtext support is tightly coupled to Xtext, but you should
> > find that it all upgrades ok on 3.8.2.
>
> the local authorities prevent me from upgrading beyond XText 2.3, i.e.
> the Juno release. Thus I cannot upgrade OCL either.
>
> Does the OCL (Pivot Model, EssentialOCL grammar and StdLib) Juno
> release receive bugfixes?
>
> Which is the branch for the Juno release in git?
>
> Thanks,
> Felix
Re: OCL binding for UML-like metamodel [message #1262265 is a reply to message #1262219] Mon, 03 March 2014 12:36 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1262395 is a reply to message #1262265] Mon, 03 March 2014 15:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

maintenance/R4_0 is Juno
maintenance/R4_1 is Kepler

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
Re: OCL binding for UML-like metamodel [message #1265914 is a reply to message #1262395] Thu, 06 March 2014 18:38 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1265982 is a reply to message #1265914] Thu, 06 March 2014 20:48 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
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.

The same number of errors is good, but zero would be better.

Try using the provided launch configurations.

You might find providing dummy @NonNull etc quicker. There is/was a JDT
patch for Juno. I think it was linked from
https://wiki.eclipse.org/JDT_Core/Null_Analysis but I can't see it ow.
You could check the history.

I think that there may be an MWE workflow option to control xtextbin.

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
Re: OCL binding for UML-like metamodel [message #1270734 is a reply to message #1265982] Thu, 13 March 2014 11:51 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1271150 is a reply to message #1270734] Fri, 14 March 2014 11:11 Go to previous messageGo to next message
Ralph Gerbig is currently offline Ralph GerbigFriend
Messages: 702
Registered: November 2009
Senior Member
Hi,

we did the same as you and Chose Option A. This works fine for us so far.

Ralph
Re: OCL binding for UML-like metamodel [message #1271183 is a reply to message #1271150] Fri, 14 March 2014 12:51 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1271506 is a reply to message #1270734] Sat, 15 March 2014 10:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The releng for builds is not-trivial so helping out is not very practical.

I cannot say definitely yes or definitely no, without seeing what's
involved.

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
>
Re: OCL binding for UML-like metamodel [message #1271507 is a reply to message #1271183] Sat, 15 March 2014 10:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
HI

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
Re: OCL binding for UML-like metamodel [message #1272677 is a reply to message #1271506] Tue, 18 March 2014 13:26 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1272748 is a reply to message #1272677] Tue, 18 March 2014 17:12 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Felix

The changes look remarkably small.

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
>
>
Re: OCL binding for UML-like metamodel [message #1272777 is a reply to message #1272748] Tue, 18 March 2014 18:51 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1272974 is a reply to message #1272777] Wed, 19 March 2014 07:58 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1273038 is a reply to message #1272974] Wed, 19 March 2014 11:14 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
Hey,

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
>
Re: OCL binding for UML-like metamodel [message #1273151 is a reply to message #1272974] Wed, 19 March 2014 15:55 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1273160 is a reply to message #1273151] Wed, 19 March 2014 16:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Have you actually tried running a back-ported Xtext editor?

It seems like you've solved the Guice/XMI/SAX problem.

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
>
>
>
>
Re: OCL binding for UML-like metamodel [message #1273599 is a reply to message #1273160] Thu, 20 March 2014 08:39 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
On 19/03/2014 17:21, Ed Willink wrote:
> Hi
>
> Have you actually tried running a back-ported Xtext editor?

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?

I will file a bug for Xtext.
Re: OCL binding for UML-like metamodel [message #1273873 is a reply to message #1273599] Thu, 20 March 2014 17:17 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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
Re: OCL binding for UML-like metamodel [message #1273962 is a reply to message #1273873] Thu, 20 March 2014 20:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I don't see how your patch works.

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
>
>
Re: OCL binding for UML-like metamodel [message #1274269 is a reply to message #1273962] Fri, 21 March 2014 08:06 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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.
Re: OCL binding for UML-like metamodel [message #1274294 is a reply to message #1274269] Fri, 21 March 2014 08:46 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
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.

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.
>
Re: OCL binding for UML-like metamodel [message #1274314 is a reply to message #1274294] Fri, 21 March 2014 09:30 Go to previous message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member
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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=400090
https://bugs.eclipse.org/bugs/show_bug.cgi?id=358853
Previous Topic:OCL validation at RCP runtime
Next Topic:uml:Extension support
Goto Forum:
  


Current Time: Tue Mar 19 04:11:19 GMT 2024

Powered by FUDForum. Page generated in 0.04977 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top