| Managing dependencies between EMF resources. [message #1736180] |
Mon, 27 June 2016 10:54  |
 Neil Mackenzie
Messages: 131
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  |
Ed Merks
Messages: 33140
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/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03224 seconds
] 
Search
Help
Register
Login
Home
