Note that my workaround for this currently is a package-private, static ThreadLocal. It widens the scope to an inappropriate level, but enables the TestEnricher to see stuff available to the DeployableContainer.
Yea, I do the same in the Weld Container. Not pretty.
There is a problem with having the DeployableContainer as an argument to the Enricher tho, they're not really connected at runtime. They could even be running in two different VMs. The Enrichment is done inside the container after deployment, so you no longer control the DeployableContainer.
In a embedded/standalone container things are a bit different, since we actually have a reference to it, but the API should reflect the common ground.
I'm about to commit the new Arquillian Core which is a bit more dynamic. If we give TestEnricher and DeployableContainer access to the Context they can share state that way.
Aslak's kindly outfitted us with a Context object to pass between DeployableContainer and TestEnricher. To take a bit of a different tack, is there anything preventing us from creating TestEnricher instances directly (no no-arg ctor required)? Same applies for the Containers and Configuration actually; what is the driving force mandating we use the Java Service Provider facilities?
If we found another way we might be able to have some more flexibility with manually assigning state to a desired component, and we could strip some of the plumbing involved with passing contexts throughout.
SPI was/is used for auto discovery of impls. No config.
Who will create the Container or TestEnricher instances? How would I add my own Enricher in the mix ?