Hi Valery,

yes, I had indeed been confused by the example. So, apologies for not having reviewed in more detail the patch.

I've now pulled the patch, just renaming some classes (CompositeStep -> Composite and related classes) to avoid a potential mixup with the CompositeStepsFactory.

The configuration of the composite paths is fine as you've envisaged it. Users can choose to name the composite files as they prefer.

Many thanks for the excellent PR.

Hi Mauro,

Sorry, it looks like, my changes in examples have confused you.

the possibility of specifying the composite as a comment in the story itself is more problematic

actually this possibility is not implemented, I've tried to follow the same pattern in examples (step_composition.story has step implementations in comments), but it looks like it may bring misunderstanding to users, so I removed comments from my examples.

1. Do you propose to have *.composites extension for files keeping composite steps? My initial proposal was *.steps.

but by default it look for .composites files in the same location of the Steps classes

This part is a bit problematic. There is a set of InjectableStepsFactory implementations: some of them rely on provided steps classes instances, some of them search for implementation using IoC containers, so there is no default "location of the Steps classes". My proposal is to use a separate configuration option for steps files.

2. Actually the textual representation of composite step is similar to Scenario. So the changes in story parsing are caused by necessity to do not copy-paste parsing logic. Story-parsing logic is not changed. If you have any suggestions how to organize parsing better and do not copy-paste its logic, I'm open for conversation.

3. Done.

Thanks

Hi Valery,

while the ability of specifying composite steps in a textual file is an entirely value-worthy improvement, the possibility of specifying the composite as a comment in the story itself is more problematic, as it breaks one of the key pillars of BDD: the clear separation between the step definition and its usages in the stories. It would also raise the probabilities of inadvertently duplicating the definitions.

I would suggest:
1. Keep the specification of composites in separate textual files (whose location should be configurable, but by default it look for .composites files in the same location of the Steps classes).
2. Leave the story parsing unchanged but add a separate composite parsing, without the need to have the definition in comments.
3. Rename keyword "Composite step:" to be simply "Composite:" in line with the annotation @Composite.

WDYT?

Hi @Mauro Talevi,

Could you please review the pull request: https://github.com/jbehave/jbehave-core/pull/186/files?w=1 ?

Thanks