mongo for key-value via maven profile

[Eric_Ace]

Our unit tests use the use the in-memory key/value store. We would like to run the same tests from the command line via maven - but use Mongo as the key/value store. We've configured local servers via templates to use mongo as the key/value store to support functional testing. In concept, to do the same thing for unit testing, I would specify a maven profile and have that profile load those same templates. (In concept.) Can you offer general guidance on approach? (The goal is to use the same unit tests un-modified against either in-memory or mongo k/v...)

UPDATED: Current approach is to do the following:

1. Use a Maven profile to set a system property like this
2. Implement a Feature - in the feature look for the property value
3. Use hot deploy in the start method of the Feature to load a contribution enabling mongo if the property indicates to do so

Of course - I don't like to duplicate work - would rather use an existing Framework Feature if one exists. Looking through GitHib, so far, I do not see it. Nuxeo folks, guidance is appreciated. Thanks.

[Kevin_Leturc]

Hello Eric,

We don't have currently a test feature for K/V store. I just created NXP-25420 for that.

Using a Maven profile + Maven Surefire plugin to inject system properties is correct.

Then you'll need a feature which is responsible to deploy the correct K/V implementation. Under your test resources, declare an OSGI bundle and a component owning your K/V configuration. In your feature start method, you'll be able to get the runtime harness and deploy your component:

public void start(FeaturesRunner runner) {
  try {
    RuntimeHarness harness = runner.getFeature(RuntimeFeature.class).getHarness();
    harness.deployContrib("org.nuxeo.kv.mongo.test", "OSGI-INF/kv-store-mongo-contrib.xml");
  } catch (Exception e) {
    throw new NuxeoException(e); 
  }
}

This should configure the right K/V to use in tests just after Framework start and before the test run.

[Eric_Ace]

Awesome - thank you. I have one follow-up... We also wish to do the same for the Stream Work Manager/Chronicle, as we transition to the Kafka Stream Work Manager. I can see a contribution