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