Hi,
> - create multiple repository.xml and workspace.xml files in > src/test/repository/** If we hard code everything, we would need to maintain a large number of such files. - no data store - FileDataStore - DbDataStore If you want to be able to test those with each persistence manager (currently we have about 12 PMs), we would have 36 configurations (3 data store * 12 pm). Also, you would need to have fixed settings for the persistence managers (fixed JDBC URLs). Then, let's say we test multiple search index configurations, you would get another dimension. For each binary setting, you would double the number of such files. I think dynamically creating the repository.xml and workspace.xml is better. > mvn > - > Dorg.apache.jackrabbit.repository.config=target/repository/repository-with-data-store.xml > install Then you would need to call mvn for each configuration. But using a system property is a good idea, what about: mvn install runs only some tests with some combinations (the most popular) mvn -Dorg.apache.jackrabbit.test=all install runs all possible test combinations (could take hours, run by Continuum) mvn -Dorg.apache.jackrabbit.testPm=derby,h2 install runs the tests with the Derby PM and the H2 PM mvn -Dorg.apache.jackrabbit.testDataStore=none,db install runs the tests with the no data store, and the db data store Another idea is to define the test combinations in a properties file: pmDerby.class=org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager pmDerby.url=jdbc:derby:... pmDerby.minBlobSize=1000 pmPostgreSQL.class=... ... testPM=pmDerby,pmPostgreSQL You could then have multiple of those properties files, and you could set which one to use using: mvn -Dorg.apache.jackrabbit.test=myconfigs.properties install runs the tests defined in myconfigs.properties Regards, Thomas
