hibernate wizard itself is locked when progress for db retrieve is started.
but progress seems to be locked by db functionality, 
for example 
	at org.netbeans.modules.dbschema.jdbcimpl.ViewDependency.getMSSQLServerPKTable(ViewDependency.java:169)
	at org.netbeans.modules.dbschema.jdbcimpl.ViewDependency.getMSSQLServerPKTable(ViewDependency.java:169)
	at org.netbeans.modules.dbschema.jdbcimpl.ViewDependency.getMSSQLServerPKTable(ViewDependency.java:169)
	at org.netbeans.modules.dbschema.jdbcimpl.ViewDependency.getMSSQLServerPKTable(ViewDependency.java:169)


Libor
trace have 50 above lines, is it ok from org.netbeans.modules.dbschema? 
Have you evaluated thread dump before move to hibernate support?

As a hint - to fix bug 239181 the same source was touched - I have two assumptions:

- There is also a self referencing structure present (maybe not only one)
- 50 is to large as max recursion level

But I only glanced at this.

I'm making a little progress on this..

Digging a little deeper into the database (it is a commercial manufacturing package) the first thing to note is that there are actually over 800 tables and a total of nearly 20,000 fields - so not trivial.

If I use the Eclipse based tools, I can generate the required hibernate.revenge.xml without any real problem (apart from the pain involved using Eclipse!).

'<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >

<hibernate-reverse-engineering>
  <table-filter match-name=".*"/>
</hibernate-reverse-engineering>
'

I can use the above in Eclipse to generate pojo (but not without errors in the Java code - see below) With slight modification I am to use the hibernate.revenge.xml in Netbeans to generate pojo and hbm.xml

'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering PUBLIC "-//Hibernate/Hibernate Reverse Engineering DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >

<hibernate-reverse-engineering>
    
  <table-filter match-schema="dbo" match-name=".*" package="com.nomogen.hibernate.xxxx"/>
</hibernate-reverse-engineering>
'

Unmodified, I was not able to generate pojo in Netbeans and in any event, the IDE became so slow whilst running the generate pojo and mapping file wizard I very nearly gave up!

The generated pojo from Eclipse and Netbeans are as expected almost identical; Eclipse is using Hibernate Tools 3.4.0.CR1 whereas Netbeans used Hibernate Tools 3.6.0

Both Eclipse and Netbeans generated pojo contain duplicate variable name errors in the Java code (is this the cause of the previously observed hang?) and these seem to be in the form of bidirectional associations between two tables and are reflected in the generated code.

I realise that many of the issues I'm seeing are due to issues in Hibernate Tools but the initial hang I reported does appear to be Netbeans related.

Can I help further? If I sanitize the database, I may be able to provide a copy in confidence.

db

Can someone from db team to look at supposed dbschema problems?
I suppose I can try to move progress initialization from edt, but it's likely stop at schema retrieval anyway , there was some problem with entities from db
see https://netbeans.org/bugzilla/show_bug.cgi?id=227678 it may be the same/similar/duplicate issue, not specific to hibernate (I see exactly the same source line here)

Yes, it's nice if you will be able to provide sample schema also.

regarding pojo generation, as you are interested, you can try latest dev build, it use hibernate-tools 4.3.1 now, but's it's  hibernate area related. Unfortunately duplicates may be a problem in 3rd party tool(hibernate tool) or some schema problems, which may cause hang also.

I'll check out 4.3.1

I had another look at the thread dump provided here and the thread dump provided by broot02_86 for bug #227678 (comment 40). The stacktraces of the analysis thread look identical. This suggest the same origin.

Based on this I close this as a duplicate of that bug. The current nightlies already contain the fix (see comment 46). Please try a current build and see if you find the bug fixed, please verify the fix in bug 227678. If you can reproduce the problem with a current nightly, please provide a new thread dump and attach messages.log.

*** This bug has been marked as a duplicate of bug 227678 ***