No servlet container for the time being. I might look at something
like httpUnit much later in the game.

Also, the next patch may include some clean up code in Hbm2DaoTest.tearDown(), and TestHelper.vistAllFiles might be visitAllFiles().

The files generated can be categorized as either a single file or a file-per-persistent-class. I have a design question (my bias injected) concerning the single files. These files consist of two interfaces, an abstract class, a utility/constants class, and, for non-managed environments, a HibernateFilter and HibernateUtil.

What package should they be in?

Your first thought may be to place them in the same package as the hbm2java stuff, which is what hbm2Dao does. This works until someone runs the generator using a configuration w/ mappings of classes in > 1 package.

The single files should be in a seperate package. Furthermore, they are the same no matter who the user is and the VTL is pretty boring/pointless. I shouldn't make a tool that copies and pastes code for others to compile; I should compile code into a component and distribute it to others. Finally, distributing this under something like org.hibernate.tool.hbm2web could be used by future contributions, like an hbm2Tapestry, which David has sworn to implement ;-)

This also has it's drawbacks. Users have to deploy their application w/ a dependency on the tools binary - something that is and arguably should stay, a design time dependency. Users also lose control over these classes (a bigger problem for HibernateUtil than for the interfaces or constants class).

Thoughts?

they should be generated to where the user wants it.

don't add dependencies back to the tools binary...

Fine, they'll have to specify a package name like they can with a jdbcconfiguration .

Why the switch from com.sun.tools.javac.Main to org.eclipse.jdt.internal.compiler.batch.Main ?

How are you getting Hbm2DaoTest to work? I'm still getting this ...

cours4\model\CoachHome.java (at line 5)
import org.apache.commons.logging.*;
^^^^^^^^^^

... even after I put this ...
<pathelement location="lib/testlib/commons-logging-1.0.4.jar"/>

... inside of $junit.moduleclasspath path element for tools/build.xml . Obviously the classpath used for the junit task is not propagated to the org...Main compiler instantiated in TestHelper .

Also, the dao exporter assumes each persisted classes is in the same package as it's respective DAO. hbm2jsf assumes this as well as well. Do you care?

hi dennis,

regarding packages then let us keep it as a mental (or jira) note as something we should/fix handle.

why switch from sun javac to eclipse ?
#1 it can compile to jdk 1.5 even when you run testcases under 1.4
#2 its faster
#3 its better documented

Apparently i haven't run the Hbm2DaoTest for a while - we probably need to expose the .jar locations to the testsuite so they can compile against it....

i plan on doing some updates/fixes to the exporter stuff later next week or start of the next so i'll look at some of these unless you beat me to it ;)

Would be good with an updated patch around that time if you have one ? Then i'll see if i can integrate it into the tools.

I'll have an updated patch in there this weekend.

For common-build.xml, there is a batchtest element beneath a target where @name="junit" . Does @fork of the batchtest element have to = "yes" ? I may have something that works for the classpath issue but it fails unless @fork = "no" - and most of the tests blow up on me w/ "yes" anyways.

I realize the DAOs are a work in progress but the static imports and the calls to getCurrentSession() mean they can only be used w/ Java 1.5 in managed environments. I'd say this eliminates 3 out of 4 users.

BTW, this thread is now more than half the length of that one about OutOfMemoryErrors!

you are more than free to fix the DAO's to work with jdk 1.4

we have a better DAO gen for the jdk 1.5 in the pipeline anyhow.

Max -

Something like a 1.4/1.5 attribute for hbm2dao? The 1.4 switch would spit out 1.4 compliant stuff using a modified version of dao.vm . The 1.5 switch would produce something similar to the stuff Christian has in CE HEAD. The velocity would be ugly if both were generated with the same stylesheet, considering the difference between the two.

We may also want to just move a switch like that to hibernatetool. There is no pretty way for the DAOExporter to tell a WebExorter "don't instantiate DAOs, use the DAOfactory".

You still didn't get back to me on the getCurrentSession() part and I think you may have overlooked the post about forking. The patch in JIRA has @fork = no.

Hi Dennis,

Keeping me busy ;)

I think we need something like java-version for the templates, the "generics" flag is not enough if we also would like to utilize static imports and other enhanced constructs.

Maybe we should simply have two different dao tasks since they are so different...i'll look into it - I also would like to find out if I should introduce something like the "snippets" feature in hibernate synchronizer since that will allow us to delegate stuff like "how to get the dao", "how to log" etc. And it will be modularized than the more all or nothing approach we have for the generators at this point.

I will also add something like a ExporterSettings object that gets instantiated for every exporter but fallsback to a parent for defaults (allowing more shared and better individual configuration)

getCurrentSession() and static import I did see and they were "covered" by my "if you have time then please fix it" statement ,)

Anyhow - with respect to getCurrentSession() I think we should generate something similar (or simply just equal) to the HibernateUtil in CaveatEmptor, which if I understood Christian correctly has been improved lately with options for handling using both getCurrentSession() and ThreadLocal depending on some heuristics/settings.

The forking I plan to look at when I find time this week to apply your jsf patch.

If you take anything from CE at this time you have to look for changes every other week, I'm making lots of changes right now.

sure - main goal is just to get some API to get the scoped factories/session/tx etc.

This is what it is does now, w/ a HibernateFilter. You can ignore the DAOs for now, they are just there for the future and are never even instantiated.

Max, David - I don't know why yet, but when using <cfg2hbm> nested beneath <jdbcconfiguration> (fresh co a few hours ago), I'm getting velocity expressions in my mapping files.

<id name="teamId" type="long" unsaved-value="$c2h.getUnsavedValue($property)">
<column name="team_id" />
<generator class="Team" />
</id>

Also, notice that the generator class is being set to the name of the persistent class. When I use this w/ the <hbm2jsf>, it cause classloading issues in the HibernateFilter because the SessionFactory tries to find an id generator called Team. This may be related to the class loading problems Max saw w/ the HibernateFilter when he reviewed HBX-367.

Anyways, I am working on a tutorial for the patch, and I think it's safe to say that it will now be using <configuration> rather than <jdbcconfiguration> ;-)