[jboss-jira] [JBoss JIRA] Closed: (JBBUILD-550) Setting up test configs

[Paul Gier (JIRA)]

     [ https://jira.jboss.org/browse/JBBUILD-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-550.
-----------------------------

    Resolution: Out of Date


> Setting up test configs
> -----------------------
>
>                 Key: JBBUILD-550
>                 URL: https://jira.jboss.org/browse/JBBUILD-550
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Sonatype
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build Support 2010
>
>
> 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. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira