Home » Modeling » OCL » OCL binding for UML-like metamodel
OCL binding for UML-like metamodel [message #1252486] |
Fri, 21 February 2014 09:08 |
Felix Dorner 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 |
Ed Willink Messages: 7670 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 #1262219 is a reply to message #1262211] |
Mon, 03 March 2014 11:36 |
Ed Willink Messages: 7670 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 #1265982 is a reply to message #1265914] |
Thu, 06 March 2014 20:48 |
Ed Willink Messages: 7670 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 #1272677 is a reply to message #1271506] |
Tue, 18 March 2014 13:26 |
Felix Dorner 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 |
Ed Willink Messages: 7670 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 #1272974 is a reply to message #1272777] |
Wed, 19 March 2014 07:58 |
Ed Willink Messages: 7670 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 |
Felix Dorner 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 #1273160 is a reply to message #1273151] |
Wed, 19 March 2014 16:21 |
Ed Willink Messages: 7670 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
>
>
>
>
|
|
| | | | | | |
Goto Forum:
Current Time: Tue Sep 24 18:43:48 GMT 2024
Powered by FUDForum. Page generated in 0.05315 seconds
|