ServerRuntime runtime = new ServerRuntime(new String[] {
"com/example/cayenne-project.xml",
"org/foo/cayenne-library1.xml",
"org/foo/cayenne-library2.xml"
});
There is also a "Merging Multiple Projects" chapter in cayenne-guide.pdf
included with 3.1B1 release. It has some more details.
Andrus
On Oct 24, 2012, at 2:58 PM, Ramiro Aparicio <[email protected]>
wrote:
> Umm I thougth a ServerRuntime could load only one configuration file, can you
> point me how can I load several?
>
> If thats possible even if the configuration must be done in a Java class (I
> would prefer XML but it is better that nothing) the only failing point is
> relationship between models of diferent modules, if they are 1-N it can be
> easily handled but N-1 or M-N are not that easy (first term is submodule
> model entity).
>
> Currently I am starting a new project very simple with low entity count so I
> will try this kind of setting as it makes a lot more sense to me.
>
> Ramiro
>
> El 24/10/2012 13:47, Andrus Adamchik escribió:
>>> I am a big fan of making everything as modular as possible,
>> me too :)
>>
>>> and this configuration helps, but what I think it would be perfect is being
>>> able to put the diferent model files in diferent modules and just
>>> orchestrate DB nodes and model composition in the project file, like a
>>> maven project.
>>> I understand that there is nothing like that currently on 3.1 but I wanted
>>> to know if any of you had experience of something like that.
>> Actually I think you can do that in 3.1. There many possible scenarios. One
>> would be a bunch of modules containing mapping-only projects, and then each
>> "leaf" module in the dependency tree (e.g. a webapp project) would include
>> them all when starting its ServerRuntime, and then configure a default
>> DataNode (per CAY-1679 this is possible in 3.1 -
>> dataDomain.setDefaultNode(..)).
>>
>> So I think a combination of DataNode-agnostic mapping projects and
>> Java-based stack assembly (that is made easy in 3.1) should give us ultimate
>> mapping modularity. If there are scenarios not well covered by this, let's
>> discuss.
>>
>> Andrus
>>
>>
>> On Oct 24, 2012, at 2:19 PM, Ramiro Aparicio <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> After upgrading to 3.1 it is now more evident that you can split the data
>>> model and data nodes as it is needed so the model can span several DBs or
>>> several models can be in the same DB.
>>> I am a big fan of making everything as modular as possible, and this
>>> configuration helps, but what I think it would be perfect is being able to
>>> put the diferent model files in diferent modules and just orchestrate DB
>>> nodes and model composition in the project file, like a maven project.
>>> I understand that there is nothing like that currently on 3.1 but I wanted
>>> to know if any of you had experience of something like that.
>>> Indeed I am not sure if it can be done as probably path to other modules
>>> models will not be the same when developing or at runtime, but I think it
>>> will be a very interesting feature for big projects.
>>>
>>> Ramiro Aparicio
>>>
>
>