Just checked in support for 1) filenameTemplate, 2) prefix, 3)
default verbose and packagedirs on (this somehow got accidentally
removed -- if you've already created eogen files, you will need to
check the box), 4) checkbox for packagedirs and java.
I just tested with your settings and it generates in packages now for
me. You should be able to explicitly check packagedirs if it isn't
already via the editor.
ms
On May 18, 2006, at 4:52 PM, Pierre Frisch wrote:
> 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 - 17:52:08 EDT