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

Reply via email to