since you volunteered to implement the migration tool, I was wondering: when do you plan to start with the implementation? I was thinking that it is maybe a good idea to put the code into a separate plug-in which you will be in charge of. Do you think that is a good idea?
Regarding the models: you can get the 2010 version of the Henshin model from the 0.8.0 branch in the repository. Maybe you can first increase the version number of the new model to 2011 only in your local version. When the migration code works, we can also increase the model version number in the trunk.
Regarding the migration method: to avoid any confusions and to make it is simple as possible, I think it is the best if you follow Stefan's approach and implement the migration as a wizard that is manually triggered by the user. Please take into account that diagram files may have to be updated too. Also, the old Henshin model should be used only dynamically and we don't want to ship extra editors for it. If you have questions on how this should be done, just drop us an e-mail.
Ciao,
Christian
2011/11/2 Christian Krause
<henshin.ck@xxxxxxxxx>
Hi,
I don't think that performance is an issue. I agree that we should support either only automatic or manual conversion.
There is a challenge that we haven't discussed yet: the diagram files need to be updated as well. Therefore, the conversion should take place in the scope of a ResourceSet, not a single HenshinResource. If we do manual conversion, there should be a dialog where you can select diagram files which should be updated together with the model file. Nevertheless, I think the update of the diagram info should be straightforward (simply pointing the view's element references to the new versions).
Ciao,
Christian
On 11/02/11 12:40, Stefan Jurack wrote:
We should stick to one or the other strategie, i.e., automatically vs.
manually triggered conversion!
Moreover, we won't roll-out two editor for two henshin.ecore version.
The standard editor for old henshin-file will be the standard sample
reflective editor with all its drawbacks.
regards
Am 02.11.2011 12:06, schrieb Riegerf@xxxxxxxxxxxx-marburg.de:
Quoting Stefan Jurack<henshin.stj@xxxxxxxxx>:
However, I am not conviced, that the migration should take place
automatically. I rather prefer a solution where the user is explicitely
required to trigger the migration, e.g., in form of a context menu or
when opening some of our editors. Afterwards, the new AND the "old"
henshin files should exist to prevent data loss.
Since we don't seem to support executing old henshin files, every
henshin file needs to be converted to the new format. I think the
automatic conversion approach is sensible. However, some aspects to
consider:
1) Automatic conversion at program runtime will impact performance.
Ideally, we should allow this for compatibility, but warn the user of
the negative impacts on performance etc. This could be done via the
IDE by creating warnings for "old" files. Where else will we brake
compatibility? Maybe "old" programs using henshin will not run anyway
and need to be refactored. If that is the case, automatic conversion
could be replaced by manually triggered conversion anyway, as it
offers no advantage and would lead to additional code in various
places, possibly making it harder to maintain.
2) Typical users likely aren't concerned about the intricacies of our
releases, so they would expect to work on some henshin files, download
the new henshin version, and then continue working on their files. An
automatic conversion will inevitably fail if the henshin file is not
"correct." Since we don't (and shouldn't!) force correctness before
saving, it is not only possible--but should be expected--for henshin
files to be un-convertible before being fixed. The user should
therefore have the opportunity to fix the henshin file if the
conversion fails and then trigger a new conversion. Since the user
shouldn't be confronted with the henshin model, we should at least
keep the tree-editor to edit the old version of henshin files.
The double-click action for old henshin files should thus be: (i)
Attempt automatic conversion (ii) If conversion is successful, open in
"2011/2012" editor, done.; (iii) If conversion fails, popup a warning
stating the file needs to be fixed before it will run again, open in
"2010" editor.
Old henshin files should display a new menu entry to trigger the
conversion. The conversion could/should (?) create a backup of the old
henshin file as filename.henshin.bak
Felix
Am 02.11.2011 10:53, schrieb Christian Krause:
Hi everybody,
version 0.9.0 will introduce changes in the Henshin model which will
break back-forward compatibility. Currently, we have two problematic
changes:
* attribute NestedCondition.negated will be removed
* class AmalgamationUnit will be removed
Therefore we need to come up with a user-friendly solution for
migrating 0.8.0 models to 0.9.0 models.
To distinguish between the two versions we will change the namespace
URI:
* version 0.8.0: http://www.eclipse.org/emf/2010/henshin
* version 0.9.0: http://www.eclipse.org/emf/2011/henshin (or 2012)
The question is how we migrate the existing 2010-models. Here is one
idea which could work:
We change the namespace URI of the generated code to 2011/12. We keep
an old version of the model file and name it, say, henshin-2010.ecore.
We register the old model dynamically (no generated code).
Now for the migration: We could transparently translate old models
when they are being loaded. For this, we change the resource
implementation (HenshinResource) such that whenever an old model is
loaded (the dynamic classes), it is automatically replaced by the new
version of the model. We would have to translate every dynamic class
by its corresponding generated class (the new version).
To incorporate the changes, we would do the following:
* If we find a 2010-version of NestedCondition which has the
attributed "negated" set to true, we wrap the generated instance in a
"Not".
* If we find an AmalgamationUnit we do not create a corresponding new
element for it. Instead, we add the multi-rules and multi-mappings
directly to the generated version of the kernel rule.
The approach has pros and cons:
pro: easy to implement; users will not be bothered with migrating
their model; in, say, 95% of the cases no problem should occur; the
old version of the model will only be overridden on disk when the user
saves the model again
con: the user might be surprised when the AmalgamationUnits suddenly
disappear. there can be cases where the automatic migration can fail.
but this is also true for other solutions.
Please comment.
Ciao,
Christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
