> >The generated classes now have a dependency upon > >commons-lang, which doesn't bother me in the > >slightest, but other people may have another > >opinion. > > Yes - me for one :) I would like to keep the generated code > as simple as possible :) (but at the same time I like to broaden > the usage of commons-lang) > > Thus, I'll suggest (and also make a patch as I get to it) that > it should be optional to have the dependency on commons-lang. > Optimal, we could generate a bare-boned toString method based > on the attributes/properties know to the metadata. >
On second thought - I'll add an option to either have the codegenerator use the methods provided by commons-lang OR not do anything at all :) The "do nothing" option is for those who want to have either a base or their own custom subclass for their classes (nicely supported by my metaattribute patch :) > >The last thing I noticed, but didn't have time > >to fix, is that subclass constructors are unaware > >of superclass properties. We need to fix that > >as soon as possible. If anyone has a chance to > >address this, I would appreciate it. > > I'll look into it. This one is more "challenging" than I thought - will take some fiddling and refactoring to do it properly....working on it (and also on making the codegen test hbm.xml files more complete/test-friendly) > And what about the meta-attribute thingy ? (it is not that a big > codechange compared to the recent commit :) (i'm just pushing here :) How about adding the meta-attribute thingy as an extra X-mas gift - it would instantly make me happy, and the codegenerator so much more better :) /max ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel