Re: deployment options discussion

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Oct 28 2002 - 16:44:41 EST

  • Next message: Craig Miskell: "Re: deployment options discussion"

    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