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).
