FYI, the way I do it: I use the singleton bean factory locator in my applications. I just use Spring for the bean factory and some programmatic transaction management, not aop style. I also used the mock jndi to simulate a container until I got away from Jboss . . .
For each project, I have three beanRefFactory.xml (sp?) files: one for prod, one for unit tests, and one for integration tests. The latter 2 are in the test-conf. I also have three normal spring config files for each app. They are named according to the same explicit convention: integration-test-PROJECTNAME-beanRefFactory.xml, or unit-test-PROJECTNAME-spring.xml, or PROJECTNAME-spring.xml. This keeps everything very clean and explicit! The bean ref includes spring files in dependent projects. I put the child project's spring config files last in the bean ref file, so I can override parent values when needed. I have 4 layers deep in some projects. The distributed artifacts for a particular project only include the prod file, never the test config. The child project is responsible for its own mocks. The difference between the prod and integration test files is usually just the datasource. My projects are small enough that I don't need to only include a subset. If you do, you probably need to shrink your projects. For web apps, I expose a static beanConfigFile name variable on my actions and servlets that allows me to change what files gets loaded. For testing non web components I just get an instance of the beanfactory locator using the appropriate bean ref file. This setup is very simple. If you extend a base unit test class or an integration test class, then you can simplify things further. . . . This results in some test cod duplicaiton, but there is no good way around it. It is often not possible to reuse the same test for both integration and unit tests, since you need to setup mocks in the latter. I use the free version of anthill running in tomcat to run maven builds. I just call ant exec with the appropriate target in my build.xml. (Ha!) I parametrize the test include to look like this: <include>**/*${test}Test.java</include> I have three builds for each project: one that builds the site docs and runs every 6 hours, one that runs all tests that runs every 2 hours, and one that runs just unit tests and runs every hour. For the unit tests I specify and argument -Dtest=Unit to just include unit tests. All tests are name *IntegrationTest.java, *UnitTest.java, ManualTest.java, or LoadTest.java. The last two are excluded from all automated builds. This allows me to use the same project xml for all my continuous integration needs. My continuous integration build also charges my in house maven repository. . . . I use maven 1.0.2. Cheers, Aaron Smuts --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]