Hibernate tools problems

gsergiu · **Joined:** Mon Sep 26, 2005 10:53 am **Posts:** 10

Finally I created a project from HibernateExt/tools folder.

It have had some problems with the classpath and some compilation problems:

1. the documentation for the build process probably need to be updated

"Some of HibernateExt modules depends on JDK 5.0 features so to build everything, you'll need a JDK 5.0 configured. Note: it is only annotations that are dependent on JDK 5.0, the rest works fine with JDK 1.4.

After that you should be able to run build.bat in the HibernateExt directory. Note, the ant based build will build everything EXCEPT the eclipse plugins.

If you need to build Hibernate 3 then run build.bat/build.sh in the Hibernate3 directory.

Note: The reason we have a .bat/.sh pair is to circumvene the need of placing thirdparty libraries in your local Ant installation."

-- From this text I unserstand that I have to checkout the HibernateExt and to run the build.bat, ... but this is not working because of classpath problems.
-- from this text I understand that building hibernate is optional, that is right ... but the tools project needs libraries from hibernate, I asume (anyway this was my solution)

2. there is a javaCompile methos in TestHelper class that usses com.sun.tools.javac.Main.compile() method, that will still not be in the classpath (tools.jar exists in jdk, but not in jre I asume).
Anyway the method is never used (except in the case of beeing used over refactoring, that I doubt),

3 Is it possible to use some defaults so that the code is compilable even without running the tests?. It doesn't look very attractive for me the following code:
/**
* @author max
* NOTE: this file cannot compile without the tests being run since its dependent on its output.
*/
public interface HelloWorld extends generated.BaseHelloWorld {

}

Best,

Sergiu

d · **Joined:** Mon Jul 04, 2005 5:19 pm **Posts:** 720

gsergiu wrote:

-- From this text I unserstand that I have to checkout the HibernateExt and to run the build.bat, ... but this is not working because of classpath problems.

Can you elaborate on problems?

gsergiu wrote:

-- from this text I understand that building hibernate is optional, that is right ... but the tools project needs libraries from hibernate, I asume (anyway this was my solution)

Using the hibernate.jar file found at http://download.jboss.org/jbosside/builds/nightly/

gsergiu wrote:

2. there is a javaCompile methos in TestHelper class that usses com.sun.tools.javac.Main.compile() method, that will still not be in the classpath (tools.jar exists in jdk, but not in jre I asume).
Anyway the method is never used (except in the case of beeing used over refactoring, that I doubt),

Are you running the tests? If not, you don't need this. If so, the dep is under testLibs.

gsergiu wrote:

3 Is it possible to use some defaults so that the code is compilable even without running the tests?. It doesn't look very attractive for me the following code:
/**
* @author max
* NOTE: this file cannot compile without the tests being run since its dependent on its output.
*/
public interface HelloWorld extends generated.BaseHelloWorld {

}

The tools are compilable w/out running tests. The interface you don't find attractive is a part of the tests, this is why it was put in a folder called testoutputdependent .

gsergiu · **Joined:** Mon Sep 26, 2005 10:53 am **Posts:** 10

dennisbyrne wrote:

gsergiu wrote:

-- From this text I unserstand that I have to checkout the HibernateExt and to run the build.bat, ... but this is not working because of classpath problems.

Can you elaborate on problems?

I was doing a copy paste of the information from the build hibernate tools webpage http://www.hibernate.org/268.html , that says that after chacking out the HibernateExt folder you should run the build.bat command. But running this script fails becuse of classpath problems.
It seems that hibernate tools are dependent on libraries found in hibernate/lib folder.

gsergiu wrote:

-- from this text I understand that building hibernate is optional, that is right ... but the tools project needs libraries from hibernate, I asume (anyway this was my solution)

Using the hibernate.jar file found at http://download.jboss.org/jbosside/builds/nightly/

gsergiu wrote:

2. there is a javaCompile methos in TestHelper class that usses com.sun.tools.javac.Main.compile() method, that will still not be in the classpath (tools.jar exists in jdk, but not in jre I asume).
Anyway the method is never used (except in the case of beeing used over refactoring, that I doubt),

Are you running the tests? If not, you don't need this. If so, the dep is under testLibs.

Even if I run the tests or not, Eclipse is placing the tests, eclipse identifies the tests folder as a source folder and after compilation I get an error (in Eclipse), and that makes me angry.

So .. I propose to remove that method, since it is not used, or to place some documentation that the tools.jar needs to be added to classpath.

gsergiu wrote:

3 Is it possible to use some defaults so that the code is compilable even without running the tests?. It doesn't look very attractive for me the following code:
/**
* @author max
* NOTE: this file cannot compile without the tests being run since its dependent on its output.
*/
public interface HelloWorld extends generated.BaseHelloWorld {

}

The tools are compilable w/out running tests. The interface you don't find attractive is a part of the tests, this is why it was put in a folder called testoutputdependent .

It stiill generates a compilation error.
If the generated.BaseHelloWorld is replaced with BaseHelloWorld, the error is removed ...

Best,

Sergiu

PS: I don't know how do you feel, but I hate when my Eclipse errors, specially when they are missconfigurations

max · **Posted:** Fri Sep 30, 2005 5:30 am

Dont you understand that this code is dependent on what some testcode will output ? That is why it is testoutputdependent and you can just remove it from your classpath.

And before you again ask why we have it that way then please remember that the tools is for codegeneration and then in any proper testsuite for that is a test for generating missing parts of existing code - thus we have a .java file that will only compile if the codegenerator is correct....

gsergiu · **Joined:** Mon Sep 26, 2005 10:53 am **Posts:** 10

max wrote:

Dont you understand that this code is dependent on what some testcode will output ? That is why it is testoutputdependent and you can just remove it from your classpath.

And before you again ask why we have it that way then please remember that the tools is for codegeneration and then in any proper testsuite for that is a test for generating missing parts of existing code - thus we have a .java file that will only compile if the codegenerator is correct....

I understand very well that they are code generators, but I also know that there are posilibilites in some situations to avoid this and I proposed one.
I don't know if ti is an acceptable solution for you ... but it works for me.

Best,

Sergiu

max · **Posted:** Fri Sep 30, 2005 6:24 am

what did you propose that "fixed" this and still made the tests test ?

That eclipse identify this as source code is not my fault, just remove the testoutputdependent from the classpath if you dont like it there - it is not needed.