Re: modeler paths

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu May 26 2005 - 12:41:17 EDT

  • Next message: Mike Kienenberger: "Re: modeler paths"

    Mike,

    Haven't tried this in a while... As long as we support subdirectories from
    the same root directory, I don't think we should go further and support
    loading DataMaps from CLASSPATH in the Modeler. This looks like asking for
    trouble.

    .... unless we start treating cayenne.xml as yet another project resource,
    and introduce a file similar to Eclipse .classpath that can be used to map
    arbitrary locations. I think Cayenne will evolve in this direction over
    time (I have some other ideas how to make configuration more flexible and
    extensible ... I guess every framework evolves into a "container" with
    time :-)), but I don't see a quick and dirty fix.

    Andrus

    > I have a model that references multiple maps in different locations. It
    > works fine from my applications (via the DefaultConfiguration
    > classloader).
    >
    > <domain name="ENG_WORK_MGMT">
    > <map name="EngWorkMgmtMap"
    > location="com/gvea/eng_work_mgmt/model/EngWorkMgmtMap.map.xml"/>
    > <map name="CoreWorkMgmtMap"
    > location="com/gvea/core_work_mgmt/model/CoreWorkMgmtMap.map.xml"/>
    > <map name="AdminDbMap"
    > location="com/gvea/admindb/model/AdminDbMap.map.xml"/>
    > </domain>
    >
    > However, the modeler itself can't deal with the paths, probably because
    > it only works with absolute file names.
    >
    > Is my only option to maintain two separate cayenne.xml files, one with
    > classpath-relative names, and the other with file-system relative names?
    >
    > Note that this file is stored in com/gvea/cayenne/model. Actually, that
    > gave me an idea. It does work if I move cayenne.xml to the root of my
    > src directory. Not exactly what I want, but I suppose it's not the
    > end of the world to have one file there.
    >
    > [Redirecting this to cayenne-devel instead of cayenne-user because the
    > real question now becomes....]
    >
    > Any ideas for fixing the model to deal with the original layout? Or do
    > we consider this an unsupportable configuration?



    This archive was generated by hypermail 2.0.0 : Thu May 26 2005 - 12:41:18 EDT