Eclipse Community Forums: OCL » Migrating code to OCL 3.5 (Eclipse 4.5)

Help

Home

Home » Modeling » OCL » Migrating code to OCL 3.5 (Eclipse 4.5)(Where can we find guidelines?)

Show: Today's Messages :: Show Polls :: Message Navigator

Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707565]

Mon, 07 September 2015 12:20

Yves BERNARD

Messages: 73
Registered: July 2014

Member

I have a java application running under Eclipse 4.4 (Luna) that makes an intensive usage of the corresponding version of the OCL SDK.

This application does not compile anymore with Eclipse 4.5 and the new version of the OCL SDK due to a significant refactoring of the OCL libraries. Some classes are simply located in another package but some others have disappeared.

Do you know where I could find documentation giving guidelines on how I can migrate from the Luna to the Mars version of the SDK?

Thanks,

Yves

Yves

Report message to a moderator

Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707568 is a reply to message #1707565]

Mon, 07 September 2015 12:37

Ed Willink

Messages: 6734
Registered: July 2009

Senior Member

Hi

Sorry, a migration guide was one of many things that did not get done
for Mars. When compromising my time, I had to take the view that users
who are clever enough to make deep use of the Pivot classes are clever
enough to migrate. Sorry again. I need 48 hour days.

The main AS classes have just migrated to new packages as you've
probably observed.

The main evolution has been to refactor MetaModelManager and friends
classes as
CompleteEnvironment/CompleteModel/CompletePackage/CompleteClass with an
OCL/EnvironmentFactory API Facade/Handle to hide most of the details.

Try to do as much as you can using
a) OCL
b) OCL + EnvironmentFactory
c) OCLinternal + EnvironmentFactoryInternal

where those aren't enough. please raise Bugzillas' with suggestions for
more helpful API.

A secondary evolution has been to isolate UML in a genuinely optional
plugin.

Flexibility/extensibility is all focusssed on the
ASResource/ASResourceFactory.

I hope that you are not using the Xtext/CS classes. My own re-use of
them for QVTd has demonstrated that evolving Xtext grammars are
incredibly fragile. I am investigating their autogeneration in complete
flat form to avoid these fragile dependencies.

Feel feel free to ask specific migration queries.

Regards

Ed Willink

On 07/09/2015 13:20, Yves BERNARD wrote:
> I have a java application running under Eclipse 4.4 (Luna) that makes
> an intensive usage of the corresponding version of the OCL SDK.
>
> This application does not compile anymore with Eclipse 4.5 and the new
> version of the OCL SDK due to a significant refactoring of the OCL
> libraries. Some classes are simply located in another package but some
> others have disappeared.
>
> Do you know where I could find documentation giving guidelines on how
> I can migrate from the Luna to the Mars version of the SDK?
>
> Thanks,
>
> Yves

Report message to a moderator

Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707574 is a reply to message #1707568]

Mon, 07 September 2015 13:17

Ed Willink

Messages: 6734
Registered: July 2009

Senior Member

On 07/09/2015 13:37, Ed Willink wrote:
> Sorry, a migration guide was one of many things that did not get done
> for Mars.
To some extent I regret promoting the Pivot code to 1.0 for Mars. There
is just no way that the residual OCL '2.5' work to support Lambda
functions, already done, and Patterns can be done efficiently within the
strict confines of API compatibility.

It has already become clear that some aspects of the auto-generated code
are intolerant of evolution; something has to change. Xtext generated
code is just one example of this problem.

EMF Core 'solves' the problem by not using the API tooling and by making
sufficiently small changes that are 'obviously' ok. I'm reluctant to
follow this path for OCL when changes are not so small and 'obviously
ok' is untenable.

Neon will have further, hopefully relatively subtle, evolution. The
major external APIs should be unchanged, but anything vaguely 'internal'
is liable to evolve. You might choose to wait for Neon when hopefully
there will be clearer overall design documentation.

Regards

Ed Willink

Report message to a moderator

Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707576 is a reply to message #1707574]

Mon, 07 September 2015 13:41

Yves BERNARD

Messages: 73
Registered: July 2014

Member

Hi Ed,

Thanks for you reply.

I didn't write this application myself and I'm afraid it does use Xtext/CS classes.

However, and at least at this stage, this is not Xtext that prevents the code from compiling. So I still hope to succeed in making it runs assuming I can understand how the code shall be upgraded. It looks like the offending code sections deal with the following concepts: domain management, resource management, metamodel management.

I'm going to study the cues you give in you first answer and go as far as as can.

I will report findings and difficulties here. I kindly invite anyone who have similar issues to do the same so that we can contribute building these guidelines.

Thanks,

Yves

Yves

Report message to a moderator

Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707583 is a reply to message #1707576]

Mon, 07 September 2015 15:30

Ed Willink

Messages: 6734
Registered: July 2009

Senior Member

Hi

On 07/09/2015 14:41, Yves BERNARD wrote:
> I didn't write this application myself and I'm afraid it does use
> Xtext/CS classes.
If you have an extended OCL grammar then you will have numerous errors
till you regenerate the models and grammars, then it all looks much
better. You might review the equivalent transition in org.eclipse.qvtd
to see the name change impact on an equivalent victim.

commit 2b02849b5e6d74f3e80b6d22b8118eb3ab270aff
Author: Ed Willink <ed@xxxxxxxx.uk> 2014-12-05 11:40:53
[ocl25] xtext, CS URI renames

commit 823c9f651f0e64bf322bfa20a84eefa140ea1641
Author: Ed Willink <ed@xxxxxxxx.uk> 2014-12-05 13:09:36
[ocl25] package, text CS renames

commit ab860d350282f9309cb50dd28570d21669a97ce8
Author: Ed Willink <ed@xxxxxxxx.uk> 2014-12-05 13:17:54
[ocl25] Pivot URI rename

If you are really using the CS classes in earnest, then I think you
should review your design. The CS has always been non-normative as
specified by OMG and internal as implemented by Eclipse OCL. Use the AS
for which Eclipse OCL is protyping a stable model.

Regards

Ed Willink

Report message to a moderator

Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1708965 is a reply to message #1707583]

Tue, 22 September 2015 22:02

Yves BERNARD

Messages: 73
Registered: July 2014

Member

Ed,

Sorry I missed your reply. For some reasons, I didn't get any notification. So, thanks for the advice.

I would also want to add a link to a message you wrote in December 2014 and that I've just found. I think it may help those who - like me - are interested by this topic. Here it is: https://dev.eclipse.org/mhonarc/lists/mdt-ocl.dev/msg01410.html

Yves

Yves

Report message to a moderator

Previous Topic:	Using getValue(Stereotype, String) with Collections. Possible bug?
Next Topic:	Collection and UniqueCollection Union

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Jun 03 10:47:32 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter