We chose to use the full model reader when running the entity-gen since there are not trivial manipulations of the en*xml files, such as extending, auto-relationships, auto-indexes, materialized views, view optimizations...
We don't entiy-gen on every build. Manually done. This is a bit of a pain, would be better if it was performed when needed. ----- Original Message ----- > Marc Morin wrote: > > We statically generate all the classes during build as you > > mentioned. We have a new ant target 'entity-gen' that runs > > after framework base util entity have been compiled. It is > > a custom container that reads the entity model, puts stuff > > into a context, then uses an ftl for the template of each > > the classes. > > container isn't needed. Use xslt, that reads all > ofbiz-component.xml+component-load.xml, recursively, then all entity > models(again, recursively), to output java. > > I've done something like this to generate makefiles that convert > entitymodel to sql stmts(CREATE TABLE (field type), CREATE VIEW AS > SELECT). I then used that to verify that my new enhanced sql reader > could read all the same model that the standard classes could. > > The xslt method would run faster, then launching a quicky ofbiz > instance, and your special container. > > > This generates two artifacts: > > > > - a class for each entity and view-entity in the system. > > - a .properties file used by GenericValue.create() to instantiate > > the correct class for the entity. > > I wouldn't generate a properties file. I would generate each java > file, compile it, store it into it's own .jar(in build/lib in the > component), and then add a META-INF/services file that lists each > entity. > > It might be nice to extend your system to handle the > Party/Person/PartyGroup pattern as well(delegator would need to be > enhanced to load the base values).
