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.
This archive was generated by hypermail 2.0.0 : Wed Jul 26 2006 - 11:15:34 EDT