Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Managing dependencies between EMF resources.(Managing dependencies between EMF resources.)
Managing dependencies between EMF resources. [message #1736180] Mon, 27 June 2016 10:54 Go to next message
Neil Mackenzie is currently offline Neil MackenzieFriend
Messages: 129
Registered: December 2013
Senior Member
Hi ,
For a project I am working on I have different resources (as XMI files) which have dependencies between them (one refers to another by loading the resource), these resources are continually being edited, and some resources that are loaded as dependant resources may be edited separately from the resources which load them. This is an almost exact analogy to plugin (bundle ) development where bundles are developed separately and their dependencies managed (via Manifest.MF files) , so for example a bundle required as a dependency can be developed further independently and its version incremented (say 4.0 to 5.0) and yet other bundles can continue to use version 4.0 ( especially if 5.0 changes the bundles API). Plugin development has a lot of tools for managing this evolving set of dependencies (calculating dependant bundles from Manifests and Targets, showing dependencies, highlighting API breakages, highlighting compilation\linking errors). I was wondering if there is any tool, or project that brings this kind of dependency management of separately evolving modules to the world of dependant EMF resources? If not I am keen to develop something (perhaps by adapting the ECP and EMFStore projects) .
Thanks for any input,
Neil
Re: Managing dependencies between EMF resources. [message #1736185 is a reply to message #1736180] Mon, 27 June 2016 11:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Neil,

I'm not aware technology that's generally trying to solve such a
problem. Certainly technologies such as EMFStore and CDO support
versioning and history, so it's possible to find historical versions of
artifacts, but the history is generally a snapshot (point in time,
revision level) of the overall state of all artifacts, and that doesn't
really given you a mixture of a combination of the arbitrary historical
state of each artifact. Inventing some mechanism that uses a logical URI
to refer to an artifact in combination with a URI mapping mechanism for
mapping that URI to the desired revision level could help solve this
problem.

For example, Ecore and GenModel resources contain cross references that
use the logical workspace URIs, but
org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap(boolean)
uses the PDE's information to map those to either something really in
the workspace, or to something in the target platform so that the
references respect the IDE's development "model" for resolving to the
correct version of the Ecore/GenModel that matches the corresponding
generated Java code.


On 27.06.2016 06:54, Neil Mackenzie wrote:
> Hi ,
> For a project I am working on I have different resources (as XMI
> files) which have dependencies between them (one refers to another by
> loading the resource), these resources are continually being edited,
> and some resources that are loaded as dependant resources may be
> edited separately from the resources which load them. This is an
> almost exact analogy to plugin (bundle ) development where bundles are
> developed separately and their dependencies managed (via Manifest.MF
> files) , so for example a bundle required as a dependency can be
> developed further independently and its version incremented (say 4.0
> to 5.0) and yet other bundles can continue to use version 4.0 (
> especially if 5.0 changes the bundles API). Plugin development has a
> lot of tools for managing this evolving set of dependencies
> (calculating dependant bundles from Manifests and Targets, showing
> dependencies, highlighting API breakages, highlighting
> compilation\linking errors). I was wondering if there is any tool, or
> project that brings this kind of dependency management of separately
> evolving modules to the world of dependant EMF resources? If not I am
> keen to develop something (perhaps by adapting the ECP and EMFStore
> projects) .
> Thanks for any input,
> Neil


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Managing dependencies between EMF resources. [message #1736647 is a reply to message #1736185] Thu, 30 June 2016 19:50 Go to previous message
Neil Mackenzie is currently offline Neil MackenzieFriend
Messages: 129
Registered: December 2013
Senior Member
Thanks Ed for those tips.
I am going to try to implement this by adapting emfstore to have the equivalent of manifest files (describing the required version of resource dependencies) and by having each resource in its own repository (so that the linking between resources is valid when the correct version of each resource is loaded into the workspace).
I will post here when I get something working.
Neil
Previous Topic:Delete
Next Topic:[xcore] derived feature does not allow class types
Goto Forum:
  


Current Time: Sat Jun 19 22:42:35 GMT 2021

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

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

Back to the top