When I launch the reverse engineering, I'm getting this: Not exactly helpful in pinning down the source of the problem.

I did rename some fields in a table, but removing the .hbm.xml for the table in question didn't help, not even after restarting Eclipse.

This is on Eclipse Helios with Hibernate Tools 3.3.0.v20101016-0359-H111-Beta1 (I assume that's the same as http://downloads.sourceforge.net/jboss/ ... 4-H111.zip , which is announced as the current development build).

I'm stumped.

Try using ant or maven to do reveng, i find the eclipse tools really buggy.

EDIT: Irrelevant configuration details removed.

UPDATE: Bisecting the revisions in the repository revealed that this happens after upgrading logback from 0.9.15 to 0.9.26, and the matching update of SLF4J from 1.5.8 to 1.6.1. There were no other changes in that update.
I guess the reveng process includes the project into its class path to make use of user-defined types and strategy classes, and then is on unstable ground when it comes to determining logging and other service classes. If that's the case, reveng should be modified to run user-provided code in its own sandbox.

UPDATE 2: I just removed the logging libraries from the subproject's build path, breaking some initialization code but reinstating the reveng process to a working state.
Seems like moving logging to a separate subproject is the way to go for me. Luckily, I'm not using any of the advanced features of logback inside, say, the reveng strategy class, else I'd be royally screwed now.

UPDATE 3: No luck with separating out logging. Usertype and strategy classes would then be stuck at whatever logging facility is available from the reveng context, which may cause the same problem.
I can work around the problem by temporarily removing the logging libs from the Eclipse project's jar export list for reveng. It's introducing the possibility of logging jars not being rolled out occasionall in the future, so I'm less than happy with that, but at least I can reverse engineer again.

Is it worth reporting the issue to Jira?

The console configuration uses just the standard classpath of the project it is in.
This is actually required. If Hibernate Tools run Usertype code, they need to pull in the jars that such usertype code might use. So - no "irrelevant" jars in this case. Stripping down the jars will mitigate the problem, but it won't solve it for everybody.
Oh, and while I agree that Hibernate Tools aren't the only Eclipse plug-in with the need to run user code (bean editors come to mind), it's still outside standard plug-in operating procedures - e.g. editor plug-ins usually don't need that. In other words, there should be a solution out there, but I don't believe that Hibernate Tools are doing it right yet.

BTW I'm not sure that sandboxing is so easy. Assume Hibernate Tools runs a bit of code from a user-defined type, and that user-defined type insists on logging something.
If the sandboxes are strictly separate, the UDT will do logging to whatever facilities the application defines. This might even crash&burn if logging is set up in a way that depends on proper initialization in main().
On the other hand, if the UDT is running in the same sandbox as Hibernate Tools, but requires a different version of Logback than what Hibernate Tools require, then depending on which version of logging is run, it will crash Hibernate Tools or the UDT.
I see no good way to resolve this. A not-so-good approach might be to at least diagnose the problem - check the two class paths, and if both share classes in different, incompatible versions, emit a warning. (The problem here being determining whether two classes are indeed incompatible. And, of course, that check could involve dealing with quite a lot of jars.)

I'm not sure what version of JBoss Tools the Hibernate Tools I'm using is part of, version numbers don't match.
The Hibernate Tools I'm using identify themselves as 3.3.0.v20101016-0359-H111-Beta1 - that's what's listed as current on the update site, so I guess I'm current.

If I do the "Use generation in external process" checkbox with the incompatible version of Logback in the class path, I get this:This happens regardless of whether I have the jar files exported or not (nonexported files seem to be left outside the class path).

UPDATE: Turns out that sometimes removing the conflicting jar from the export list is enough, sometimes I need to removed them from the classpath. Might be related to whether Reveng was run or not.

Yes, output is to the sources folder, and projects are auto-built.
It's entirely possible that the IncompatibleClassChangeError stems from changing entity classes. I can't easily check that though, the error mesage doesn't name it (chalk up another paper cut to whatever code is generating that message, and another one to the code that doesn't spend the extra line of code to generate a stack trace).
I'm mildly curious why reveng needs to instantiate an entity class in the first place, though. And if it does, why it isn't placing such entities in a separate sandbox (maybe because it's all too easy to introduce silent bugs, so building sandboxes requires effort and experience which may not be readily available).

I can confirm that automatic regeneration kicks in while reveng is still busy generating POJO code.
It might be a good idea to somehow postpone automatic project regeneration. Eclipse does offer ways to specify dependencies between tasks, mybe automatic project regeneration should be made to wait until reveng has finished? This might not only fix the IncompatibleClassChangeError issues, but also speed up the reveng process. Redoing dependency analysis over and over is bound to burn a few cycles, particularly in a project of 5000+ classes like the one I'm doing.

I don't think that separating the output directory will be a workable solution: Hibernate Tools reveng needs the user types in the class path, and the user types will draw in all the logging and other potentially conflicting stuff.
In the long term, Hibernate Tools should probably run any user type code in a separate sandbox, i.e. inside the project's classpath.

For now, I simply remove the logging jars from the project's build path, then I reveng, then I reinstate the original build path by reverting the .classpath file from SVN.
It's a kludge and may grow problematic as Hibernate Tools and my project's code develop more jar incompatibilities, but it's a good enough stopgap solution.

Sorry for the double post, but since all that I have right now is a stopgap solution, I'd like to hear whether there are any plans to move this towards a permanent solution, and whether I can reasonably help with that.

but is there any chance that I'll be able to use a better solution than the current stopgap one?
Tips & hints appreciated, reference to a JIRA entry would work too (I think this would become several loosely-related JIRA issues, but I don't want to put stuff into JIRA that isn't helping move Tools along).

The problem is that Hibernate 3.6 has a class change from class to interface which means it is source compatible but not binary compatible with Hibernate Tools.

That plus other binary changes causes this problem and is recorded in https://issues.jboss.org/browse/JBIDE-8071

Thus the "workaround" is when you need to generate code with hibernate tools then don't include hibernate 3.6 on the classpath; the resulting code can be used fine with 3.6 afterwards.

The challenge is that if we added 3.6 support we would loose 3.3-3.5 support too.
Thus for now we are not updating but will try and see what we can do going forward.

If you want to help out with that then do please let us know.

Thanks, the feedback is greatly appreciated.

And yes, I also have Hibernate Tools on the classpath - it's part of the magic incantation that made user types work. I'm not so sure that binary incompatibilities between Tools and Hibernate are the cause, removing just logging made it run just fine (but then I may have been just lucky).

FWIW here's the list of logging jars:
jcl-over-slf4j-1.6.1.jar
jul-to-slf4j-1.6.1.jar
slf4j-api-1.6.1.jar
slf4j-ext-1.6.1.jar
logback-classic-0.9.26.jar
logback-core-0.9.26.jar
I don't know which of these actually trigger the problem, the error message pointed me towards the innards of logging, so I decided to remove it all, and lo! it worked.

if you run just from within eclipse "our" version of hibernate takes over and then yes, its just "3rd party" dependencies that can conflict.