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
|