Hi,
As for QVTo dependencies. As Ed mentioned QVTo utilizes only three plug-ins of Classic OCL:
org.eclipse.ocl
org.eclipse.ocl.common
org.eclipse.ocl.ecore
Being bundled along with QVTo will make the latter fully self-contained. So I believe repackaging Classic OCL this way looks like a rational solution.
Regards,
Sergey.
Hi
You are looking at minor dependencies for which the OCL aspect is
unwise/obsolete/irrelevant.
The major dependencies are QVTo and Papyrus; other projects should wait
to see what these projects do.
The constraint aspect of Papyrus is heavily dependent on the new Eclipse
OCL that exploits Xtext. This is unlikely to survive long before the
infrastructure needs an at least minor rebuild. The OCL usage of Xtext
uniquely avoids tight coupling but some Xtext evolutions tend to require
a compatibility tweak.
QVTo is heavily dependent on the old Classic Eclipse OCL that is very
stable. However an infrastructure evolution will eventually break it. If
the remaining QVTo committer is enthusiastic, the classic OCL plugins
could be folded into QVTo and, if exported, could be used to satisfy the
minor dependencies.
(QVTd is still an incubation project that has failed to popularize an
OMG standard. It has very few users. Not needed in SimRel.)
Regards
Ed Willink
On 03/04/2024 18:06, Ed Merks via cross-project-issues-dev wrote:
>
> Thanks. Yes, I was already looking at EMF Services' dependencies
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
