Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Migrating code to OCL 3.5 (Eclipse 4.5)(Where can we find guidelines?)
Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707565] Mon, 07 September 2015 12:20 Go to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 67
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
Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707568 is a reply to message #1707565] Mon, 07 September 2015 12:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5429
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
Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707574 is a reply to message #1707568] Mon, 07 September 2015 13:17 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5429
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
Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707576 is a reply to message #1707574] Mon, 07 September 2015 13:41 Go to previous messageGo to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 67
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
Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1707583 is a reply to message #1707576] Mon, 07 September 2015 15:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5429
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
Re: Migrating code to OCL 3.5 (Eclipse 4.5) [message #1708965 is a reply to message #1707583] Tue, 22 September 2015 22:02 Go to previous message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 67
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
Previous Topic:Using getValue(Stereotype, String) with Collections. Possible bug?
Next Topic:Collection and UniqueCollection Union
Goto Forum:
  


Current Time: Thu Oct 19 14:20:42 GMT 2017

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

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