Thanks very much Mike. This is amazing it even parsed the file I
created manually!!!
Pierre
On 18-May-06, at 2:52 PM, Mike Schrag wrote:
> 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 - 18:56:54 EDT