|
Re: Question wrt EMF Services [message #1854475 is a reply to message #1854474] |
Sun, 21 August 2022 00:06 |
|
Hi, Geoffry,
I cannot comment on active development of these components. However, the EMF Transaction API is a core component of GMF-based applications such as Papyrus and others such as the EMF.Cloud Model Server. The main use case for the EMF Validation framework is transaction validation in EMF Transactions. As much as possible, you should let this framework delegate to the validation implemented in your model in the usual EMF way. I know of very few use cases outside of the original UML scenarios for which it was originally developed in which you would need the constraint provider capability of this framework.
HTH,
Christian
|
|
|
|
|
|
|
Re: Question wrt EMF Services [message #1854498 is a reply to message #1854495] |
Mon, 22 August 2022 18:38 |
Ed Willink Messages: 7669 Registered: July 2009 |
Senior Member |
|
|
Hi
EMF Delegates like EMF is nothing to do with the Eclipse UI. While facilities like the EMF Editor need the UI, invoking e.g. eGet() can be performed standalone. EMF Delegates is the functionality behind e.g. eGet() that invokes an appropriate handler.
Behind the scenes OCLinEcore is just XML magic in the form of EAnnotations in an Ecore model. The OCLinEcore editor enables you to edit in a much more acceptable fashion than XML tweaking or Tree pigeon holing , so yes you need the IDE for an editor, but not for model execution.
Ditto: Java. It's hard to develop Java code without an IDE, but once built it can run without an IDE.
Regards
Ed Willink
[Updated on: Mon, 22 August 2022 18:43] Report message to a moderator
|
|
|
Re: Question wrt EMF Services [message #1854555 is a reply to message #1854498] |
Thu, 25 August 2022 06:55 |
|
Hi,
I am currently the only maintainer of EMF Services (Query/Validation/Transaction). I was not involved in their original developement, but we use them extensively in Sirius and other of our products at Obeo, so when the previous maintainers moved to other projects, we decided to take over their maintenance.
As a mere "user", I am not an expert on the internals of either EMF Validation or EMF Transaction, so I'm reluctant to make significant changes to their internals.
As far as I'm concerned, the functional scope of these components is "done". EMF Validation and Transaction have worked fine as they are for years (decades?) for a multitude of projects, and I don't plan to make significant changes to them.
My goal for these projects is only to make sure they continue to work reliably and stay compatible with the ecosystem: recent versions of Java, Eclipse Platform, Tycho, etc. For example I recently released EMF Validation 1.13.0 and 1.13.1 (https://github.com/eclipse/emf-validation/blob/master/RELEASE_NOTES.md) and EMF Transaction 1.13.0 (https://github.com/eclipse/emf-transaction/blob/master/RELEASE_NOTES.md) to make sure they are compatible with the upcoming Eclipse 2022-09.
I may merge the occasional bugfix or cleanup if I am confident enough it will not break existing users, but tend to be conservative here. Lots of existing projects depend on these components working in the way they have been for years, so even things that can look like "improvements" can have unintended consequences (https://www.hyrumslaw.com/).
The projects have moved to GitHub at https://github.com/eclipse/emf-query, https://github.com/eclipse/emf-validation and https://github.com/eclipse/emf-transaction. Contributions welcome, with the above caveat about being extra-careful.
Regarding EMF Query, I am not aware of any actual user (EMF Parsley has a dependency on it, but it does not seem to be actually used), so as mentioned on the project page (https://projects.eclipse.org/projects/modeling.emfservices) and on GitHub (https://github.com/eclipse/emf-query), this one is no longer maintained at all. I made one exception recently and released a version 1.12.1 to avoid the issue with ICU4J, but that's only because Parsley still depends on it, and I don't plan to ever make another release of it. Unless of course someone elses is interested and wants to get involved.
Regards,
Pierre-Charles David (Obeo)
PS: Sorry for the longish message, but I guess this thread is a good opportunity to clarify the status of these projects.
PS2: The story is mostly the same for GMF Notation & Runtime.
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
Powered by
FUDForum. Page generated in 0.03527 seconds