Summary

Add HK2 DI support.

Details

The HK2 module follows the patterns used by the Guice dependency module. An annotation binding scope named @ScenarioScoped has been added, which when set as the binding scope for a class, will limit the object's lifespan to the lifespan of a Cucumber scenario. I.e. a new instance of this object will be created for each Cucumber scenario.

The HK2 ServiceLocator used by the module is provided by the user's implementation of ServiceLocatorSource. Expose your implementation to the Cucumber runtime by setting the environment key hk2.locator-source to the fully qualified name of the implementing class.

The easiest way to do this is by creating a cucumber.properties file with the configuration values, and placing this file at the root of your classpath.

Note: Your provided ServiceLocator MUST have the ScenarioScopeModule binder installed!

If you do not provide your own custom ServiceLocatorSource, a default ServiceLocatorSource will be created by the module. This default ServiceLocator will be populated by services found in the META-INF/hk2-locator/default file, as would be created by the HK2 inhabitants generator.

Motivation and Context

There was an open issue and pull request created late last year to do the same thing, however, after going over it, I decide the patterns used would not fit our needs (I need to be able to provide an already populated service locator).

Taking a look at the Guice module I noticed it seemed a bit more flexible, so I decided to rewrite the module using cucumber-guice as a model.

How Has This Been Tested?

I am using the same test scenarios and classes used by cucumber-guice, reimplemented for hk2.

I have copied the ElementMatcher and CollectionUtil test classes because I was not sure whether I should move these classes into a shareable module (like cucumber-core test classes)

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.