Improved Plugin API

[mpkorstanje]

Issues with the plugin system

1. Concrete plugin implementations should not be in core. Plugins tend to use third party dependencies. We have to shade these in or suffer the dependency. Doing this in core make the core heavier then it needs to be.
2. We can't list all available plugins (for CLI options).
3. Third party plugins must be referenced by FQN while our own plugins have short names.
4. Input validation should happen when parsing. Currently happens at plugin instantiation.
5. URLOutputStream is an abomination.
6. No support for Path and FileSystem APIs.
7. The use of standard out is implicit in the constructor arguments of the plugin.
8. Appendable can't be closed but we trick around that in NiceAppendable.
9. OutputStream argument must always be closed. Plugins however can't tell if Cucumber crashed and thus can't clean it up. This should be done by Cucumber (it created the stream so it owns it).

Solution

1. Register and create plugins with SPI.
2. Provide interfaces to create an instance of a plugin from specific arguments
3. Remove Appendable as valid argument.

Something in that direction anyway.

[naveenchandra91]

Is there also a plan to add an api which provides a minimal representation of some pickles(For some detailed third party reporting it needs Feature pickle etc) as a part of this feature request?

[mpkorstanje]

Currently the pickles are available as TestCase objects in the TestCaseStarted/Finished events. Each event has a collection of TestStep objects that contain the information about either steps or hooks.

There currently is no good way to access how the pickles are organized in a feature and I hope to unlock that with #1870. But that will be a very generic tree structure. It won't for example contain the outline steps in a Scenario outline.

So it depends on how much detail you'll need. For AST level detail you'll have to parse the features yourself or wait for cucumber messages to be integrated with Cucumber JVM which will include a well defined json schema for the AST.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

[mmuzikar]

I am working on a project that'd benefit from a more flexible plugin structure, can we make a deal where I'll rework the plugins and you let me add some features (such as reading registered stepdefs from glue, accessing type transformers etc.)

I started working on separating the plugins to their own small modules and not surprisingly this will break compatibility so it might be a good opportunity to introduce some wanted changes.

I am proposing these changes:
All plugins will implement the Plugin interface which requires to implement the activate method with an PluginActivationContext parameter. This method will be called only when the plugin is activated in the configuration (html[:output] in CucumberOptions, arguments or ENV). This change is needed because SPI creates the plugin instances while it's loading the plugins, so gone are the days of arguments in constructors.

Also to avoid FQN for "3rd" party plugins each plugin can be annotated with @PluginMetadata: @PluginMetadata(name = "html", description = "Html formatter", version = "v0.0.1"), to specify shorter name, and other things like description and version for listing available plugins. (with possible extensions for describing arguments?, websites?)

Another change would be removing interfaces like SummaryPrinter (which I saw was deprecated), EventListener... and this all would be handled by the plugin via the ActivationContext.

Also coming: more config options! I'd like for the plugins to have the ability to be more configurable, the config values would be accessed via the ActivationContext as well.

Another useful feature would be to open outputstreams/writers via the ActivationContext as well, so the resources get autoclosed, but I need to look at how the plugins handle their outputs, maybe the context won't create them but you'll be able to register your AutoClosables to get closed automatically.

Any arguments to my proposal or other changes that would be appreciated?

[mpkorstanje]

I'll rework the plugins and you let me add some features (such as reading registered stepdefs from glue, accessing type transformers etc.

If you are looking to access the glue context from a plugin, perhaps it is best to explain underlying use case. It could be that a plugin may not be the right solution or there may be a different solution all together. Could you create a new issue for the changes you actually want done?

[mmuzikar]

I described the use case in #2239

[mpkorstanje]

Another consideration comes from cucumber/junit-xml-formatter#27.

Plugins may need to access have configuration options, somehow....