In a Class Diagram there isn't a visual cue to distinguish members that are tagged as generated or not. Sometimes I forget that a member in a Class should no longer be generated by HiberObjects. I sometimes need to say change the name of that member and I do so in the Class Diagram but forget that HiberObjects won't reflect that change in my .java file.

This sounds like a good idea. I'll try implement it in the next release.

/Lars

Hi Lars,

Also perhaps you can allow a User to choose to allow different aspects of a member's definition to be regenerated. At the moment the existence or absence of a @generated tag is an all or nothing approach. Perhaps you can add 2 more variants of the @generated tag such as:

@generatedsig

would allow HiberObjects to only regenerate a member's signature and would leave the javadoc and the body of code for that member as-is.

@generatedbody

would allow HiberObjects to only regenerate a member's body of code and would leave the javadoc and signature as-is.

If a User combines:

@generatedsig
@generatedbody

then HiberObjects will regenerate a member's signature and the body of code but leave the javadoc as-is.

Regards,
Stephen

I think it would be best to never overwrite the Javadoc because HiberObjects never generates it (as far as I can remember). Don't know how much work that is though.

The method bodies are only overwritten for accessors (get-, set-, add- and remove-methods) and for designed objects (initObjects and some related setUp). Other method bodies are left as the user edited. Do you mean that the accessors should not be regenerated? And do you then mean all accessors, or individual ones?

If I implement this, I think I will make tag parameters like "@generated signature" etc instead of "@generatedsig" etc.

Regards,
Lars

I just remembered that HiberObjects can generate Javadoc from tags designed by the user. And this is the reason I am regenerating the whole Javadoc, to avoid merging designed and implemented Javadocs. So then perhaps a "@generated javadoc" or something is needed.

/Lars

Hi Lars,

This is from my own experience so I obviously cannot speak for others and hopefully they will speak up if they disagree with my assumptions for all Users...

From a usability point of view I find it more user friendly and more productive to enter my Javadoc comments using the Eclipse Java editor rather than editing them on a Class Diagram using HiberObjects and why reinvent? So I guess I would prefer if HiberObjects could reverse engineer my edited javadoc comments and display them on a Class Diagram as-is rather than allow me to edit them on a Class Diagram. From my point of view when I want to edit javadoc I would prefer an option in HiberObjects to edit Javadoc and then the Java editor would be opened at the javadoc so I can edit it. Once I finish editing the javadoc using the Java editor and save it I can use the Eclipse Go Back feature to return to the Class Diagram. Perhaps HiberObjects could then be smart enough to know the javadoc has been saved and then automatically reverse engineer the javadoc into the Class Diagram and display it for me.

So basically this approach would mean, use the Eclipse Java editor for what it is best for: editing Javadoc. Use HiberObjects for what it is best for: creating classes, members, etc.

Regards,
Stephen

I agree.

/Lars