[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mdt-bpmn2.dev] Working on the ecore merger tool
- From: Benedikt Ritter <beneritter@xxxxxxxxxxxxxx>
- Date: Fri, 30 Mar 2012 16:48:30 +0200
- Delivered-to: firstname.lastname@example.org
sorry, but I'm having the feeling that we are going round in circles :-)
I suggested to split up the large ecore model into smaller submodels
with respect to the separation in the spec. Reiner argued that the
ecore get's generated and that the merger tool would have to be
extended to to the job.
So I looked through the open issues and saw Bug 357088 - XML
Serialization: incorrect order of children
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=357088) where the
suggested solution also was to change the merger implementation.
Now I'm thinking of ways to change the merger and Henning argues, that
the ecore models better has to be maintained by hand, because changing
the merger requires to much work.
I guess you have to decide for one:
- change the merger to fit the needs and fix bugs at a very abstract level
- only change the ecore and leave the merger as is
There are pros and cons for both ways. I personally think, that new
BPMN specs are published to infrequently, that maintaining the merger
really pays off. I think adjusting the ecore by hand is doable. But I
would also jump right into a refactoring of the merger tool if you
decide to do that. Let's just make a decision, but then stick to it
Am 30. März 2012 15:42 schrieb Henning Heitkötter <hheitkoetter@xxxxxxxxxxxxxx>:
> So far, I (and we as a project) have neglected the maintenance of the
> merger tool in favor of changing the Ecore file directly, because the
> latter is easier to do and requires only one generation step, instead
> of two (Merger + Genmodel).
> What would be preferable with respect to new releases of the
> specification depends on the kind and amount of changes in these
> releases :-). However, if there were too many changes to apply them
> manually, we could still implement a new merge tool (based on the
> existing one), which could also incorporate our manual changes.
> So, in my opinion, we should dedicate our limited resources to other
> areas first.
> One thing to keep in mind if we decided to update the merger anyway /
> sometime: the genmodel file was also modified manually. Hence, we
> would have to check, which of these changes affected individual
> elements and how to align them with the merger.
> 2012/3/30 Benedikt Ritter <beneritter@xxxxxxxxxxxxxx>:
>> the general question is, where are you going with the merger tool? Do
>> you want to use it for subsequent releases of the spec? Then the
>> project has to be in a maintainable state, with unit tests,
>> checkstyle, findbugs, etc.
>> Special configuration issues as mentioned by Henning should be
>> extracted from the code to some sort of config file (as far as
>> If on the other hand, migrating the ecore by hand to a new spec
>> release is far less effort then re-generating it and adjusting the
>> generated model, it should be considered to drop the merge tool
>> If you see a chance for bringing the tool up to date, then I'll start
>> right away, by writing some tests.
>> Am 30. März 2012 14:28 schrieb Henning Heitkötter <hheitkoetter@xxxxxxxxxxxxxx>:
>>> Hi all,
>>> I recently had a look at the merger tool and generated a merged Ecore
>>> file for testing purposes. I found that our ecore file has diverged
>>> from the automatically generated file in a lot of areas. (Of course,
>>> you can also look at the git log for the file to see these changes.)
>>> I also had some problems with attribute types (the ecore file that I
>>> had generated from the CMOF file only used EJavaObject), but that
>>> might have been due to some configuration issues on my side.
>>> While I think that bringing the merger tool up-to-date with these
>>> changes might be useful for future changes to the specification, be
>>> advised that it will likely require a lot of work and manual
>>> modification of the generated file (or special rules) might still be
>>> necessary, as not all changes can be deducted from the specification
>>> (CMOF + XSD) alone.
>>> 2012/3/29 Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx>:
>>>> Hi Benedikt,
>>>> I'm fine with the idea. Feel free to reorganize the project to fit to Maven convention structure. Only note that for bundles (for which we use tycho), the structure is different and more PDE like - and bundle tests go to extra bundles or fragments.
>>>> Am 29.03.2012 um 22:40 schrieb "Benedikt Ritter" <beneritter@xxxxxxxxxxxxxx>:
>>>>> I'm planning to put some effort on the ecore merger tool, since there
>>>>> are several issues related with that tool (e.g.
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=357088 or the discussed
>>>>> splitting of the ecore model). However, I'm feeling uncomfortable,
>>>>> touching the code because there are no unit tests. So the first thing
>>>>> I want to do is to write some unit tests.
>>>>> Now at my company we use maven. Maven has a convention for the project
>>>>> structure, where unit tests reside in special source folder called
>>>>> src/test/java. Since the ecore merger tool does not stick to this
>>>>> convention, I do not know where to put my unit tests. I've seen the
>>>>> test bundle but I don't think that it is the right place for the ecore
>>>>> merger unit tests. So where should I put the tests?
>>>>> After bulding up a basic test coverage (and ATM I don't know how much
>>>>> effort that will be), I'd like to try to split the code up some more.
>>>>> The processor has several concerns that it has to deal with, and it
>>>>> would be good to separate concerns.
>>>>> mdt-bpmn2.dev mailing list
>>>> mdt-bpmn2.dev mailing list
>>> mdt-bpmn2.dev mailing list
>> mdt-bpmn2.dev mailing list
> mdt-bpmn2.dev mailing list