I think we definitely need the ability to have more than one
cayenne.xml. As you point out, only one can exist at the moment, which
limits "importing" cayenne based frameworks. 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).
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).
Do these comments help?
Craig
On Sat, 2002-10-26 at 10:18, Andrus Adamchik wrote:
> Now that Cayenne has matured during the past few months and I gained some
> real life deployment experience, I am looking for ways to ease the
> deployment process.
>
> Basically, current limitation is that in any VM there can be only one
> "cayenne.xml" file referencing the maps and connection info.
>
> While, "single cayenne.xml" approach is simple and great for smaller
> projects with a single persistence JAR file, this limits the ability to
> import Cayenne-based "persistent frameworks" in your application to just one
> per application.
>
> What I am suggesting to do is to provide Ant and/or GUI tools that would
> help packaging and deploying Cayenne in many different ways. Anyone could
> comment if this makes sense?
>
> 1. Single app deployment - current type of deployment, when cayenne.xml and
> all the files it references are JAR/WAR-ed together and are deployed with
> the app (either from CLASSPATH or from WEB-INF)
>
> 2. "Cayenne Module" deployment (new) - a regular JAR file that only contains
> DataMap files and any class/resource files that are part of the module (no
> cayenne.xml or connection info is included). Such module is not a standalone
> application, but one or more of such modules can be deployed with other
> applications.
>
> 3. Application using "Cayenne Modules" - any Java application that uses
> persistent classes packaged in "Cayenne Modules". It will have a
> "cayenne.xml" file that references maps from "modules", while providing its
> own connection info and association between the maps and physical
> datasources.
>
>
> While we already support (1) now, and creating (2) is trivial, (3) requires
> some thought. Simplest way of implementing it would be an Ant task that
> extracts DataMap files from "modules" and "injects" the links to them to an
> existing cayenne.xml. This is rather dynamic and maybe just all we want. I
> will work some more on the Ant and possibly GUI interface design for this.
>
> Comments?
>
> Andrus
>
This archive was generated by hypermail 2.0.0 : Mon Oct 28 2002 - 15:37:28 EST