Status: Closed (View Workflow)
Resolution: Out of Date
Affects Version/s: None
Fix Version/s: Maven Build Support 2010
Similar Issues:Show 10 results
JBBUILD-410 Set up retro jdk1.4 build and test of microcontainer on hudson. JBBUILD-156 setting basic properties on init JBBUILD-589 Add pom validation to the repository test config JBBUILD-438 Set up some ant/maven deployment scripts for hibernate entitymanager JBBUILD-444 Complete the AOP maven migration JBBUILD-204 test JBBUILD-352 VFS tests fail under mvn JBBUILD-357 Eclipse PDE integration into Maven and unit test failure JBBUILD-644 Apache snapshots repo config JBBUILD-107 Test changes with 4 0 build integration
From Max's email:
When we run hibernate testsuite we today configure every run by having a <profile> section.
Each profile setup its own dependencies (i.e. jars for the classpath) and properties used
in interpolation of files like hibernate.properties.
This works pretty well and even works good with IDE's since you can just do:
mvn -Pdb2 test
then maven will generate the right hibernate.properties and run the tests.
Then in your IDE (eclipse, netbeans, intellij, whatever) can just use the generated hibernate.properties file
and pickup the jars. Nice and simple.
The downsides of this are:
A) To test a custom config you have to edit the pom.xml which becomes tedious when that file is under svn and thus becomes dirty
even though you haven't really changed anything in here.
B) There is not a clean way of having downstream adopters use our testsuite to run the testsuite.
A could be solved in a couple of ways:
1) create a "custom" profile which will pick up settings from lets say "custom.properties" to get the connection information. But then we would be missing the jar dependencies.
2) Another way would by being able to have profiles stored external to the pom.xml. Steve mentioned profiles.xml being discussed at some point to allow for this.
3) create a separate project per testsetup, but then we bump into other issues:
- surefire not being able to run tests based of tests in a jar. Not even when explicitly naming the class.
- Having a test subclass per config is also not scalable since it would just be tons and tons of boilerplate code with zero differences in plus without the easy "build project + dependencies" this becomes hard to maintain.
- And finally when it is a separate project it becomes cumbersome to run this easily from an IDE (the test class is in separate location, and so is the hibernate.properties)
- No way of overriding hibernate.properties since additional classpath entries are appended not prepended to the classpath when running tests.
B) could also be solved with the profiles.xml option or separate project - but have similar issues as described above.
I hope that put some more light on the issues ?
Let me know if it makes sense/nonsense.