EOGenerator editor provides an interface to editing a lot of these
options already (definitely the things you list in your ant target),
but the deal is that you can pass in multiple -model's, so you can't
define these inside the eomodel file, because it would potentially
cause conflicts. In the general case I think you have to end up with
something like our .eogen files. Also, you can right click on an
eogen file now and select "WOLips Tools=>EOGenerate ...". I might be
able to put that action on EOModel also and just have it find all
the .eogen files that reference it. As far as only generating SOME
entities, I'm not sure that you can tell eogenerator to do that? You
might be able to, I've just never seen a restriction. However, it
won't actually write the files if there aren't changes anyway, so it
shouldn't cause issues (a performance hit doing the comparisons,
though).
On Jul 26, 2006, at 11:08 AM, Watkins, Garry wrote:
> This is what my ant tasks for eogen look like, I was thinking all
> of the model specific parameters that you would want passed to
> eogenerator.
>
> <target name="eogen.CMP">
> <exec dir="." executable="/Developer/Applications/WebObjects/
> eogenerator">
> <arg line="-model CMP.eomodeld"/>
> <arg line="-destination src"/>
> <arg line="-packagedirs"/>
> <arg line="-templatedir ../Templates"/>
> <arg line="-verbose"/>
> </exec>
> </target>
>
> <target name="eogen.FileRoom">
> <exec dir="." executable="/Developer/Applications/WebObjects/
> eogenerator">
> <arg line="-model FileRoom.eomodeld"/>
> <arg line="-destination src"/>
> <arg line="-packagedirs"/>
> <arg line="-templatedir ../Templates"/>
> <arg line="-verbose"/>
> </exec>
> </target>
> But there are a whole slew of options that are available (copied
> from the eogenerator README file), that could be model specific. I
> took out the objc related items. Some of the options with encoding
> can probably be ignored or set in a higher level properties or
> configuration file.
>
> Invocation Options
> There is only one required parameter to the program; the EOModel
> must be specified. In most situations custom templates will be
> used, and if so these need to be specified as well. The parameters
> can be can be used in full, or as substrings where unique (e.g. -
> destination can be specified as -d or -dest). The order of options
> is not important.
>
> Only one kind of of classes can be generated at once. If more than
> one type is needed (e.g. regular and client-side classes) then
> eogenerator must be invoked multiple times.
>
> -java
>
> Specifies that Java source code files are to be generated. Java is
> the default for WebObjects 5.x projects; Objective-C is the default
> with WebObjects 4.5 and earlier.
>
> -javaclient
>
> Specifies that Java client source code files are to be generated,
> which use slightly different templates by default and could
> potentially have a different class name. Implies -java.
>
> -model modelpath (this one would automatically be generated)
>
> Loads the EOModel found at modelpath, and generates classes for all
> entities found inside (unless specific entities are given on the
> command line).
>
> -refmodel modelpath
>
> Loads the EOModel found at modelpath, but does not generate classes
> for its entities (unless specific entities are given on the command
> line, in which case this is the same as -model). This is useful if
> you only want to generate entities for one model, but need to load
> other models to resolve all of the relationships in the main model.
>
> -force
>
> Force overwriting of read-only files. By default, read-only files
> will not be overwritten, and a warning message printed instead.
> This can be a useful reminder in some revision control environments
> to check out the necessary files first.
>
> -destination destinationdirectory
>
> Used to specify a destination directory for generated source code
> files. By default, files are generated in the current directory.
>
> -subclassDestination destinationdirectory Used to specify a
> destination directory for the empty subclass source code files.
> This allows the generated files and the actively edited source to
> be placed in different directories. By default, the subclass files
> are generated/looked for in the -destination directory.
>
> -packagedirs
>
> When doing Java generation, creates directories corresponding to
> the Java package name components underneath the -destination
> directory. This will generate the classes into a typical Java
> directory structure. [Note that the old ProjectBuilder, still
> sometimes used on Windows, does not support classes laid out in
> this manner. Xcode should not have this problem.]
>
> -prefix string
>
> Uses string as the prefix for the generated class names (to
> distinguish them from the real EO class names). By default this is
> a single underscore ( "_").
>
> -templatedir directory
>
> Prepends directory to the search path used to find template files.
> Multiple -templatedir flags can be specified; the directories will
> be searched in the order they appear on the command line.
>
> -sourceTemplate file
>
> -subclassSourceTemplate file
>
> -javaTemplate file
>
> -subclassJavaTemplate file
>
> Used to specify alternate template files to use. file can be an
> absolute path, a relative path, or a filename found in one of the
> search path directories. If not specified, the default templates
> are used.
>
> -filenameTemplate string
>
> This argument causes string to be used as a MiscMerge template,
> with the result being used as the base name for the generated
> files. Normally, filenames based on the entity's class name are
> used, which is sufficient for most situations. Occasionally it can
> be useful to have custom filename patterns (coupled with custom
> templates), and this parameter can allow for a lot of flexibility.
> For example, if you want Java interfaces to be generated along with
> the classes, a template of "{javaClassName}Interface"
>
> will cause `Interface' to be appended to each filename. The
> delimiters for this template are `{' and `}', and the base object
> is the EOEntity instance (just like the regular class templates).
> Regular EOEntity methods can be used as keys, as can entries in the
> userInfo dictionary. When generating Java classes, if the generated
> filename has what looks like a Java package, it will override the
> package normally specified in the EOModel.
>
> The boolean variables "isSubclass" and "isSuperclass" are defined
> for use in if statements as necessary. For example, to generate the
> abstract superclasses into a separate "eogen" subpackage, something
> like the following can be used (coupled with changes to the
> templates of course):
>
> -filenameTemplate '{classPackageName}{if isSuperclass}.eogen{endif}.
> {classNameWithoutPackage}'
>
> -encoding enc
>
> Specifies the character encoding to be used for generated files.
> The name can be specified as a value returned from the NSString
>
> +localizedNameOfStringEncoding: method, or (on MacOS X) an IANA name
>
> (typically what Java uses). Defaults to the local platform string
> encoding.
>
> -templateEncoding enc
>
> Specifies the character encoding to be used when reading template
> files.
>
> Defaults to the value specified for -encoding.
>
> -define-key value
>
> This option adds the specified key-value pair to the list of
> variables available to the template, in addition to the EOEntity
> methods. A key specified in this manner will not come before an
> EOEntity method of the same name when the template searches for the
> value.
>
> -verbose
>
> Causes more verbose debugging output to be logged to standard output.
>
> I was also hoping to have right clickability on the model or an
> entity to run eogenerator for what ever was clicked on. That way I
> would not have to re-generate all of the entities if I just changed
> one entity.
>
> Garry
>
> From: Mike Schrag [mailto:mschra..dimension.com]
> Sent: Wednesday, July 26, 2006 10:42 AM
> To: woproject-de..bjectstyle.org
> Subject: Re: Entity Modeler fetch specs
>
> What information would you want to store in the model? .eogen
> files can contain multiple models (sort of like composite indexes),
> so we can't really put configuration information into a single
> eomodel -- it has to live in something above the model level.
>
> On Jul 26, 2006, at 9:39 AM, Watkins, Garry wrote:
>
>> This is just a note of warning if you are using eogenerator to
>> generate static methods that call fetch specifications. Since the
>> new Entity Modeler now orders the plists, eogenerator is
>> reordering some of the parameters that are being generated, thus
>> causing method signatures to be different. To fix this I have
>> modified my eogenerator to sort the bindings array by name,
>> therefore it will always generate the method signature in the same
>> order as long as I do not add new bindings to the fetch spec. But
>> I am going to find the places where I am calling the code, to make
>> sure it is calling them correctly, for the cases where I send in
>> multiple parameters of the same type.
>>
>> I just ran into this problem, so I thought that I would warn people.
>>
>> Mike, were you doing the eogenerator modifications too? If so,
>> couldn't we use the same methodology that you are going to use for
>> indexes and to store the eogenerator parameter information in the
>> eomodel.userInfo dictionary? Then we could store the eogenerator
>> path in the wobuild.properties file.
>>
>> Thanks
>> Garry
>>
>>
>>
>> Confidential & Privileged
>>
>> Unless otherwise indicated or obvious from its nature, the
>> information contained in this communication is attorney-client
>> privileged and confidential information/work product. This
>> communication is intended for the use of the individual or entity
>> named above. If the reader of this communication is not the
>> intended recipient, you are hereby notified that any
>> dissemination, distribution or copying of this communication is
>> strictly prohibited. If you have received this communication in
>> error or are not sure whether it is privileged, please immediately
>> notify us by return e-mail and destroy any copies--electronic,
>> paper or otherwise--which you may have of this communication.
>
>
> Confidential & Privileged
>
> Unless otherwise indicated or obvious from its nature, the
> information contained in this communication is attorney-client
> privileged and confidential information/work product. This
> communication is intended for the use of the individual or entity
> named above. If the reader of this communication is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly
> prohibited. If you have received this communication in error or
> are not sure whether it is privileged, please immediately notify us
> by return e-mail and destroy any copies--electronic, paper or
> otherwise--which you may have of this communication.
This archive was generated by hypermail 2.0.0 : Wed Jul 26 2006 - 11:29:52 EDT