When configuring a DataSet using an annotation, it makes perfect sense that a DataSetProvider is configured using a reference to a class that implements the DataSetProvider interface. When using RiderDSL however, it makes more sense to configre an instance of a class implementing the interface, as in the example below (taken from a customer project where we integrate DbRider with the Karate DSL test framework):

    private void execute(SeedStrategy strategy, IDataSet dataset)  {
        RiderDSL
            .withConnection(jdbcConnection)
            .withDataSetConfig(new DataSetConfig()
                .datasetProvider(() -> dataset)
                .strategy(strategy)
            ).createDataSet();
    }

I.e. given a IDataSet created elsewhere, allow a lambda implementation of DataSetProvider to provide that dataset.

The DataSetConfig.datasetProvider() could be overloaded to allow both a class (when used from an annotation) or an instance (when used via the RiderDSL). The only additional change required is to move the instantiation of a DataSetProvider from a configured class into that same DataSetConfig.datasetProvider() instead of doing it in DataSetExecutorImpl as of today.

I'll prepare a pull request with this minor change.