| Re: [henshin-dev] Technical details for Henshin model migration |
We won't roll-out two editors for two henshin.ecore version. If anyone wants to stick to the old henshin-version, he should keep its old plugins with the "right" editor, i.e., plugins with version <0.8.x Am 04.11.2011 10:49, schrieb Riegerf@xxxxxxxxxxxxxxxxxxxxxxx: > Quoting Stefan Jurack <henshin.stj@xxxxxxxxx>: >> 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. > > Users usually aren't concerned with internal model changes. With > increasingly better graphical editors for transformation rules, the > internal model has become less and less important for the user. > Correctness of the henshin file is not enforced before saving, so a > 'broken' henshin file can be saved. I guess this happens a lot during > rule development. > What we're trying to do is to convert a henshin file from the old > model to the new model. Obviously, this will only work if the henshin > file we're trying to convert is not only correct, but also follows > some of the new model's conventions. If the conversion fails for any > reason, the user will be presented with an error and is now required > to fix the file before attempting a conversion again. Normally, the > user should now be able to open the henshin file in question, modify > it and start a new conversion. However, since currently we don't plan > to supply the old editor, the user will now have no editor support > whatsoever; this means errors in 'old' henshin files will be hard to > find, editing will be very complicated, slow and error-prone. For > small rulesets, creating the rules anew will probably be faster than > trying to find an error and fix it using the sample reflective editor. > This should never happen! Users should be concerned with working with > the system, not editing their previously editable files with an > extremely basic and overly complicated editor. > > Shipping two editors will alleviate the problem. We should at least > support the users in model migration, so one option to distribute the > old editor(s) would be putting them in an optional package for the > user to download separately. > > Felix >
Attachment:
signature.asc
Description: OpenPGP digital signature