Re generics: that's a missing feature. The code generator predates Java 5. Probablyyou can use the JavaVersions class to decide whether to do generics or not. Re interface changes: enhance away! -Patrick On 5/23/07, Gokhan Ergul wrote: > Patrick Linskey wrote: > >> Would you guys be interested in getting donations in that area? > > > > Certainly! > > > >> We do have our homegrown solution that does that (along with some other > >> goodies as well). It's currently based on our metadata representation > >> reverse-engineered from the database schema, it'd be nice (read: more > >> flexible and maintainable) to have it based on openjpa metadata and > >> integrated in openjpa itself for the community to use. > > > > The basics could be implemented as a new subtype of > > ReverseMappingTool.ReverseCodeGenerator that did more intelligent > > things in the various field / method generators; ideally, we'd want to > > provide options for things like leaving ORM metadata in XML but > > putting @Entity and @Id etc. in classes, and obviously the ability to > > not write any XML at all and put everything in annotations instead. > > Finally had some time to look into this. Quick question: it seems we > don't support generic collections for "to-many" relations while > generating code --is that deliberate or just a missing feature I could add? > > About subtyping ReverseMappingTool.ReverseCodeGenerator: it goes a bit > beyond that. To generate class annotations, I'll need to mess around > with openjpa-kernel/.../enhance/CodeGenerator, at the least promote > getClassCode(String packageDec, String imports, ...) method from private > to protected --least impact, but hardly an elegant solution. Is it ok if > I make a few enhancements there (obviously preserving existing behaviour)? > > Gokhan. > -- Patrick Linskey 202 669 5907