Craig Miskell writes:
>
> Do these comments help?
>
Absolutely. I was trying to wrap my head around this problem for about 4-5
months now. A fresh view is really needed.
> It also means that for a
> given set of projects (all accessing overlapping portions of an
> underlying database) that the persistence layer cannot be split into
> multiple chunks (like having multiple eomodels in WO... a very useful
> conceptual thing).
WebObjects deployment structure has an advantage of being able to identify
frameworks and their resources explicitly. So cayenne.xml in a predefined
location (be it a CLASSPATH, or WEB-INF for web applications) was designed
to fill in this gap, and avoid hardcoding configuration in the code.
> I think option 3 is definitely the way to go... it allows "split" models
> (conceptually split) and multiple distinct models (separate vendors
> maybe), while still permitting the application final say on mapping Maps
> to Nodes. Despite the extra work I really really really think it's
> worth it.
>
> As for how: An Ant task sounds interesting... I'm not sure how much it
> buys us ... all the connection info and path specification for the
> "Cayenne module" will need to be specified in the build.xml, which will
> then be transformed into not much less verbose cayenne.xml. I just
> don't see the advantage, unless you're intending on physically
> extracting the DataMap xml files from the cayenne module and shoving
> them near the cayenne.xml. I don't think that's a good idea as then the
> datamap could trivially become out of sync with the classes (if the ant
> task doesn't get run for some or any reason). IMHO, cayenne.xml should
> reference the datamap.xml only, probably qualified by module name (to
> avoid file name clashes).
I guess when deploying a module, we can modify "cayenne.xml" of the source
project to be called "module-name.cml" or something (or allow starting
module projects via GUI from the beginning). Module will NOT have any
connection info (DataNodes). Application will have its own project that has
a "cayenne.xml" as a main integration point (so it is still one per VM), but
would allow linking with named modules - just like you suggested.
This seems like a sensible way to solve deployment of multiple libraries,
though it will require serious GUI modifications. I wonder what holes still
need to be plugged here?
There is one more problem left to solve : how to allow an easy change of
connection information across the environments. But this is a separate
issue...
Andrus
This archive was generated by hypermail 2.0.0 : Mon Oct 28 2002 - 16:44:45 EST