Hi Mike,
I am having trouble with the new feature.
I used to launch eogenerator using the "old feature" with the the
following arguments:
-model "Resources/BlackPressDirectory.eomodeld" -refmodel "Resources/
Prototypes.eomodeld" -templatedir Templates -destination src -prefix
_ -filenameTemplate "{classPackageName}{if isSuperclass}.base{endif}.
{classNameWithoutPackage}" -packagedirs -verbose -java -define-
copyrightYear "2006" -define-copyrightBy "Black Press"
I understand that the UI does not support some of the feature I need
so I manually edited the eogen file to:
/Developer/Tools/eogenerator -model "Resources/
BlackPressDirectory.eomodeld" -refmodel "Resources/
Prototypes.eomodeld" -templatedir Templates -destination src -prefix
_ -filenameTemplate "{classPackageName}{if isSuperclass}.base{endif}.
{classNameWithoutPackage}" -packagedirs -verbose -java -define-
copyrightYear "2006" -define-copyrightBy "Black Press"
However it still does not do what I need. The classes get generated
at the root instead of being placed in a sub-directory base. Any idea
what may be different? Do you know where the log goes, I cannot see it?
Thanks
Pierre
On 15-May-06, at 4:25 PM, Pierre Frisch wrote:
> 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 : Thu May 18 2006 - 16:52:23 EDT