I think it's actually the other way around ... I think the scope
would need to be all the projects that DEPEND on this one (rather
than all the projects that this project depends on).
For example:
Accounting Framework Project
Accounting Model
Accounting.eogen
Business Management Project
depends on Accounting Framework
Business Management Model
BusinessManagement.eogen (has a refmodel Accounting Model)
Accounting Model is modified. We now need to find all the .eogen
files that might reference this model. The results in this case
would be Accounting.eogen and BusinessManagement.eogen that need to
be regenerated.
The general rule then being, 1) look for eogens in the same project
as the modified model, then 2) look for eogens in all the projects
that depend on the project that contains the modified model.
However, I /think/ that the only potential case where this causes a
problem is cross-model inheritance where you have a method that
generates based on inherited attributes. This SHOULD be kind of
rare, I think, but we can do the full-blown search impl if people
prefer it.
ms
On Jun 26, 2006, at 11:49 AM, Pierre Frisch wrote:
> Thanks Mike
>
> I would think the correct behavior to be all open project this
> project depends upon. That would limit the scope if the project
> hierarchy is correctly built.
>
> Pierre
>
> On 24-Jun-06, at 8:54 PM, Mike Schrag wrote:
>
>> Automatic eogeneration is back ... It's off by default, but you can
>> turn it on in the WOLips build preferences. When a model is changed,
>> EOGeneratorBuilder looks for all the .eogen files in the same project
>> that reference the modified model, and kicks off an EOGenerate action
>> for them.
>>
>> I'm curious to get opinions on the search scope. Right now it only
>> hunts in the same project, but obviously models can cross projects.
>> If you modify a model, would you want it to look through all open
>> projects for any referencing eogen files? Obviously you take a
>> performance hit to do this (it's a lot more hunting), but it's
>> TECHNICALLY the more correct behavior.
>>
>> ms
>>
>
This archive was generated by hypermail 2.0.0 : Mon Jun 26 2006 - 12:00:00 EDT