Re: EOGenerator support

From: Pierre Frisch (pierre.frisc..pearway.com)
Date: Mon May 15 2006 - 19:25:27 EDT

  • Next message: Ulrich Köster: "Re: Can't get the latest nightly upgrade"

    Hi Mike,

    When you have time prefix and filenameTemplate would be a help. I
    agree that packagedirs and java should just be on and verbose is
    quite useful when debugging but not life threatening; actually you
    could set it on by default I don't think it would cause any problem..

    Here is an example of a eogenerator target I use:

         <target name="generate.eos">
             <exec dir="${project.dir}" executable="/Developer/Tools/
    eogenerator" vmlauncher="false" outputproperty="eogen.log"
    logError="true" newenvironment="true">
                 <arg value="-model" />
                 <arg file="${project.dir}/Resources/Catalog.eomodeld" />
                 <arg value="-refmodel" />
                 <arg file="${project.dir}/../sPearWayAccess/Resources/
    Prototypes.eomodeld" />
                 <arg value="-templatedir" />
                 <arg file="${project.dir}/../sPearWayAccess/Templates" />
                 <arg value="-destination" />
                 <arg file="${project.dir}/src/" />
                 <arg value="-prefix" />
                 <arg value="_" />
                 <arg value="-filenameTemplate" />
                 <arg value="{classPackageName}{if isSuperclass}.base
    {endif}.{classNameWithoutPackage}" />
                 <arg value="-packagedirs" />
                 <arg value="-verbose" />
                 <arg value="-java" />
                 <arg value="-define-copyrightYear" />
                 <arg value="1997-2005" />
                 <arg value="-define-copyrightBy" />
                 <arg value="sPearWay Ltd." />
             </exec>
             <echo message="EOGenerator ${eogen.log}" />
         </target>

    I think having a separate auxillary xml build file to be called in
    the general build would be quite acceptable, It would work in my case
    anyway.

    Thank you

    Pierre
    On 15-May-06, at 3:39 PM, Mike Schrag wrote:

    > I don't support the full set of commands yet (basically just what I
    > use :) ) ... prefix and filenameTemplate aren't in there at all.
    > Verbose is in the model, but not in the UI. Packagedirs is always
    > on (not sure why you would NOT want this on?). Having destination
    > and subclassDestination separate actually matches the EOGenerator
    > configuration options. I point both of mine to "src", which it
    > sounds like what you want to do also. Those two folders define the
    > location from which package directories will be created.
    >
    > Now that we have a model that tells us the EOModels associated with
    > an eogen file, we can hook it back up to the build process so it
    > runs when there are changes.
    >
    > I'm all for an ant task, though I'm not sure how to make a
    > build.properties with LISTS (i.e. you can have a variable number of
    > models and ref models). I could, however, actually generate a mini
    > ant target xml that can be included/called from the larger build.xml.
    >
    > Can you send me the example ant xml of how you currently call
    > EOGenerator from your build script?
    >
    > ms
    >
    > On May 15, 2006, at 6:26 PM, Pierre Frisch wrote:
    >
    >> Hi Mike,
    >>
    >> I am not sure how to use the new feature. Here is the parameters I
    >> used to pass to eogenerator in WOLips:
    >>
    >> -model "Resources/BlackPressDirectory.eomodeld" -refmodel
    >> "Resources/Prototypes.eomodeld" -templatedir Templates -
    >> destination src -prefix _ -filenameTemplate "{clas
    >> sPackageName}{if isSuperclass}.base{endif}.
    >> {classNameWithoutPackage}" -packagedirs -verbose -java -define-
    >> copyrightYear "2006" -define-copyrightBy "Black Press"
    >>
    >> I can find a way or reproducing most of them but how do I set
    >> "prefix", "filenameTemplate", "packagedirs" and "verbose"
    >>
    >> Also the settings "destination" and "subclass destination" are a
    >> bit counter intuitive; I usually store my subclasses in a package
    >> directory (com.blackpress.ldap in that case) and my generated
    >> classes in a sub directory base inside the same package
    >> (com.blackpress.ldap.base in that case). To achieve this I need to
    >> put src in the destination and nothing the subclass destination.
    >>
    >> I also think we need a way of forcing eogenerator to run when we
    >> are doing a "full build" for distribution or release. I kind of
    >> liked the idea of having it run whenever the model has changed
    >> even if I have find it a bit unreliable.
    >>
    >> How do you see the ant integration? instead of the xx.eogen file
    >> could we make it a property file and have a target in the standard
    >> build.xml to call eogenerator with those properties? May be in
    >> woproject? That would save us from having to maintain two sets of
    >> parameters.
    >>
    >> Thanks for the work I think we are on the right track.
    >>
    >> Pierre
    >>
    >> On 15-May-06, at 11:09 AM, Mike Schrag wrote:
    >>
    >>> The latest wolips (124) adds a little nicer support for
    >>> EOGenerator. I went the route of how Eclipse supports .jardesc
    >>> files for producing jar files. The first thing you should do is
    >>> setup the fields in the WOLips=>EOGenerator preferences. Next,
    >>> use the new EOGenerator wizard (under the WOLips section of the
    >>> New.. window), and fill in the attributes of your eogenerator
    >>> configuration. To execute it, you can right-
    >>> click=>WOlips=>EOGenerate... the file. I have not tried this on
    >>> Windows at all, and I suspect there will be some escaping of
    >>> backslash issues at the very least. You can have multiple .eogen
    >>> files in your project if you have different sets of eogenerator
    >>> configurations. It's a first-version, so bear with it :) I'm
    >>> pretty annoyed with the file/folder selection dialogs that
    >>> eclipse provides -- on the Mac, none of them appear to default to
    >>> the folder that I specify, which is pretty annoying.
    >>>
    >>> One thing also is that if you change your global EOGenerator
    >>> preferences after having created eogens, your .eogens will need
    >>> to be updated (reopen, remove explicit references to default
    >>> values, and resave). The eogen file itself is actually a one-
    >>> line script that you can run from the shell also. I have no idea
    >>> if this is useful to anyone. It makes life kind of annoying to
    >>> maintain, so I might toss that if nobody has an opinion on it.
    >>>
    >>> ms
    >>>
    >>
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon May 15 2006 - 19:25:31 EDT