@karl:
imo it's the responsibility of the container itself to provide different approaches to find such a config (via param. should be just one of it) and it's a feature which is just portable in theory since only one container (we support out-of-the-box) supports that at all.
however, i'm ok with that suggestion since it doesn't pollute the api itself.
@all:
everybody is welcome to suggest better names, however, we need "deltaspike." as prefix for the project-stage based config (since it can be provided by any config-source and that's our prefix we use already) and the default config for the test-container is META-INF/apache-deltaspike_test-container.properties since we have META-INF/apache-deltaspike.properties as name already and it should be clean for users that it isn't a config for deltaspike itself, instead it's a config picked up by deltaspike and forwarded to the test-container.
for sure we could reuse META-INF/apache-deltaspike.properties, but imo it's strange to see other deltaspike-config-values in the test-container (e.g. during debugging)
I've implemented a 2-staged lookup.
A first lookup will check for a "cdiTestRunnerConfig" property via ConfigResolver (default of this value is "cdiTestRunnerConfig" again).
This value will be used to pick up property files (via PropertyLoader, thus you can use many of them and use ordinals to tweak values) which will get feeded into CdiContainer#boot(bootProperties).