I'm not convinced that the .hbm.xml files are being acted on properly if they are generated in the same "pass" as they are being read in.


I'm reverse-engineering a database in order to generate the POJO classes, "xxxHome" classes, .hbm.xml files and hibernate.cfg.xml file.
I've defined some of my own templates used to generate the .hbm.xml files.
I've then defined some templates used to generate the Java code.

I've found that if I attempt to generate everything in one single pass, the <meta attribute="xxxx">yyyy</meta> inserted into the .hbm.xml files by my templates had no effect on the Java code that was generated.
e.g. my id.hbm.vm template file contains a clause
<meta attribute="scope-set">protected</meta>
If I generate everything in one single "hit" (i.e. exporters for "generate domain code", "JDK1.5 constructs", "generate DAO code", "generate mappings", "generate hibernate configuration" and "generate schema html-documentation" were all ticked), then my setId method remains "public".
If I use two passes; the first pass to generate the hibernate.cfg.xml file and the .hbm.xml files, and the second pass that generates the POJO and xxxHome java code, my setId method is protected (as expected).

Has anyone else seen this or is it just me?

Hibernate tools version: TOOLS_3_1_0_BETA3

eeh yes. Its pretty hard for the first pass to provide you with a hibernate model you can use based on the output of it self!

Of course you need to generate the hbm.xml files first if you want something special in them that should be used when generating something from it.

Hmm.
I'm not sure that this behavior follows the "principle of least surprise".
I expected the output of the reverse-engineering tool to be the same whether one generated each file-set seperately in individual "passes" or did the lot in one go, just as I would expect the output of doing an "ant" build on a freshly downloaded project should product the same .jar file as if one had built it by telling ant to build each intermediate task before generating the final jar file - the output should be the same whether it did it in one "pass" or in more than one.

I appreciate that there may be algorithmic reasons why this isn't the case, but I would suggest that this doesn't necessarily make it desirable.

so javac <somefiles-that-when-run-generates-code> should be able to take the not yet generated code into account ?!

That sounds like a big voodoo-magic to me ;)

the first part uses a <jdbcconfiguration> to read additonal mapping info from a database and then generate data based on this, the second part uses a normal <configuraiton> to read the generated mappings from the first step and then generate from that.

Javadoc only documenting code that existed, yes, that's understandable ;) However a "javadoc" task in a build system should (I believe) be coded such that all the code was generated before it was invoked, in order to ensure that it didn't matter whether one said "ant javadocs" or "ant" or "ant generate_source javadocs".

What I expected is that the POJO stage would read the data outputted by the HBM stage regardless of how many stages I asked it to do it in. After all, if it's doing it all in one button-press, it just means that the code does the HBM stuff then goes on to do the POJO stuff without asking the user for any further prompting?

(Note: This is not a major issue for me anymore. However it was a major issue before I found this out because I had previously come to the conclusion that templates didn't work, as nothing I did on the HBM files had any effect on the POJO output)

and i fully agree with your point, but note that <hibernatetool> is a single ant *task* - it is not a ant *target* and thus if one <hibernatetool> generates something it simply can't "restart" and run on the output. It requires a second <hibernatetool>.

The individual exporters inside <hibernatetool> simply works on the configuration generated by the <xxxconfiguration> in sequence, nothing more nothing less.

I would love input on how to explain this bette so people can avoid this assumption (because you are not the first).

Understood.

As to how to prevent such misunderstanding in future... Well, I came at this from Eclipse, not an ant task, so I would suggest an addition to the Eclipse plugin GUI code:
If the user has the "generate mappings (hbm.xml)" ticked AND also has ( "generate domain code" OR "generate DAO code" ) ticked THEN warn them (e.g. using a read-only text box positioned beside the tick-boxes) that these will all be generated in one go and any template customisations to the mappings will have no effect on the POJO/DAO code.

Either that or make the GUI invoke the underlying reverse-engineering code twice if the user asks for both to be generated - once for the mappings and again for the rest - that way they need not even know about the issue as it will work regardless of how they invoke it.


As for ensuring that ant users don't fall into the same mistake, I'm not so sure, as I've not looked at this side of things at all.
I would have hoped that a well commented example that defines two distinct ant targets, one generating mapping files and one doing everything else, with the second dependent on the first, should convey all that needs to be said.

ah you are from the ui-dark-side ;)

I can understand well how it can be confusing from that side. point taken.