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 <[EMAIL PROTECTED]> 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
