Eclipse Community Forums: GMF (Graphical Modeling Framework)

Home » Modeling » GMF (Graphical Modeling Framework) » Visual ID and graceful migration?

Visual ID and graceful migration? [message #117530]

Thu, 05 April 2007 18:47

Eclipse User

Originally posted by: khai.n.situvista.com

I have a fairly robust GMF editor for a large XML Schema/EMF model that
is already being used by the client to create artifacts; the model and
editor are going through enhancement iterations, and the model and
diagram are in separate files.

Adding new elements to the XML Schema is pretty straight-forward and the
newly generated EMF code can open and manipulate older model files
without conflicts and without having to implement migration logic.

When it comes to the diagram files I find that I will have to implement
manual conversion from one version to another when new elements are
added to the editor or else the new editor can not load older diagram
files. This is because of a few things:

1. The diagram file stores the View ID as the 'type' for a node
2. The View ID is generated by the "Create generator model..." process
where it generates and stores the View ID for each node in the .gmfgen
file
3. Under 'certain' condition when new elements are added through .gmfmap
the View ID's are regenerated and some existing nodes are given a
different View ID.

Simplified example: An existing diagram with a Link Mapping 'A' with
View ID = 4000, a new node 'B' is added through .gmfmap , the generator
then gives 'A' a new View ID of 4001 and the new node 'B' the View ID of
4000. Clearly this would mean that any previously created diagram file
is no longer consistent and therefore can not be loaded with the new
editor.

Current Work-around:

1. Manually 'reassign' View ID through editing .gmfgen before generating
diagram code (this is tedious and error-prone because it has to be done
manually each time something changes in .gmfgraph/.gmfmap)

2. Re-init the diagram from the model file (this is a viable option for
simple models but the model I have is location-sensitive to where each
element is in relation to others on the canvas; and that information is
stored in the .diagram file which I can no longer load therefore the
diagram files would have to be converted before opening)

3. Manually convert the older .diagram files through raw text editing
(we all know how error-prone this can be)

Questions:

Is there a setting to tell the generator to NOT assign new View ID to
existing nodes?

Is there a specific order to add new elements to .gmfgraph/.gmfmap to
ensure that existing View ID are not changed?

Thanks in advance for any helpful hints

-- Khai --

Re: Visual ID and graceful migration? [message #117585 is a reply to message #117530]

Fri, 06 April 2007 06:30

Eclipse User

Hello Khai,

Proposed solution for now is to install org.eclipse.gmf.bridge.trace plugin
(part of sdk.experimental distribution). This plugin will create additional
..trace file during .gmfmap -> .gmfgen transformation and will use it to dispatch
visualIDs on next transformation. You can easily modify this file in case
of some complex changes, but for the situations like: new mapping was added/removed
default .trace file should be sufficient.

Known problem: on first .gmfmap -> .gmfgen transformation all the visualIDs
will be changes due to the different logic used in bridge.trace I suggest
you to perform this transformation, re-generate the code and re-create all
the diagrams. This is only one migration which should be done. Mostly all
the following .gmfmap mode modifications should be automatically processed
by trace plugin.

-----------------
Alex Shatalin

Re: Visual ID and graceful migration? [message #117666 is a reply to message #117585]

Fri, 06 April 2007 16:13

Eclipse User

Originally posted by: khai.n.situvista.com

Thanks for the pointer, Alex, this seems like a viable long-term
solution which I will look into integrating into my workflow.

Unfortunately, for now, I can not integrate an 'experimental'
plug-in because the client wants to work with API's that are
relatively guaranteed to not change between minor updates:-(

Well it looks like custom code for now and potentially using the
....trace capabilities in the long run.

Thanks again for the help.

-- Khai --

Alex Shatalin wrote:
> Hello Khai,
>
> Proposed solution for now is to install org.eclipse.gmf.bridge.trace
> plugin (part of sdk.experimental distribution). This plugin will create
> additional ..trace file during .gmfmap -> .gmfgen transformation and
> will use it to dispatch visualIDs on next transformation. You can easily
> modify this file in case of some complex changes, but for the situations
> like: new mapping was added/removed default .trace file should be
> sufficient.
>
> Known problem: on first .gmfmap -> .gmfgen transformation all the
> visualIDs will be changes due to the different logic used in
> bridge.trace I suggest you to perform this transformation, re-generate
> the code and re-create all the diagrams. This is only one migration
> which should be done. Mostly all the following .gmfmap mode
> modifications should be automatically processed by trace plugin.
>
> -----------------
> Alex Shatalin
>
>
>

Re: Visual ID and graceful migration? [message #118096 is a reply to message #117666]

Tue, 10 April 2007 09:00

Eclipse User

Hello Khai,

> Unfortunately, for now, I can not integrate an 'experimental' plug-in
> because the client wants to work with API's that are relatively
> guaranteed to not change between minor updates:-(
>
> Well it looks like custom code for now and potentially using the
> ...trace capabilities in the long run.

I would strongly recommend to use .trace plugin here. ;-) This plugin is
a part of sdk.experimental distribution now nevertheless there were a number
of requests asking to make it available as a part of GMF. We are going to
publish it on GMF update site as a separate feature and I think it is pretty
stable and reliable. Even in case this plugin functionality will be changed
we will provide you with the migration path.

-----------------
Alex Shatalin

Re: Visual ID and graceful migration? [message #203412 is a reply to message #117585]

Tue, 26 August 2008 10:57

Eclipse User

Originally posted by: michael.wohlfart.proceedinnovation.com

Alex Shatalin schrieb:
> Hello Khai,
>
> Proposed solution for now is to install org.eclipse.gmf.bridge.trace
> plugin (part of sdk.experimental distribution). This plugin will create
> additional .trace file during .gmfmap -> .gmfgen transformation and will
> use it to dispatch visualIDs on next transformation. You can easily
> modify this file in case of some complex changes, but for the situations
> like: new mapping was added/removed default .trace file should be
> sufficient.
>
> Known problem: on first .gmfmap -> .gmfgen transformation all the
> visualIDs will be changes due to the different logic used in
> bridge.trace I suggest you to perform this transformation, re-generate
> the code and re-create all the diagrams. This is only one migration
> which should be done. Mostly all the following .gmfmap mode
> modifications should be automatically processed by trace plugin.
>
> -----------------
> Alex Shatalin
>

Hello!

I have the same problem Khai had more than a year ago. I made sure I had
installed the .trace plugin, but the .trace files are not showing up in
the project.

Do I have to enable the generation of these files somewhere, or am I
just searching in the wrong place?

Maybe worth mentioning, I'm still using GMF 2.0.1.. migration is planned
til end of year...

Greetings,
Michael Wohlfart

Re: Visual ID and graceful migration? [message #203453 is a reply to message #203412]

Tue, 26 August 2008 12:17

Eclipse User

Hello Michael,

> Maybe worth mentioning, I'm still using GMF 2.0.1.. migration is
> planned
Are you sure you've installed proper version of trace plugin?
Once traces plugin is installed in your configuration trace functionality
should be always "on".

-----------------
Alex Shatalin

Previous Topic:	plugin(s) required to enable svg in gmf?
Next Topic:	injectExpressionBody problem

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 18 06:25:08 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter