Exclude SCM patterns from ScenarioClassNameFinder

Actually, the Ant DirectoryScanner already has the SCM patterns excluded by default.
The problem of SVN files being included in the finder lookup doesn't seem to be reproducible - at least on command-line.

It seems though from thread on list that issue occurs withing IDE. So more details are needed to reproduce and verify (possibly a sample project).

Descoping until an example to reproduce behaviour is available.

This issue reproduces stable if we have <configuration> section is placed only under <execution> section, as in \examples\gameoflife\pom.xml:

<plugin>
<groupId>org.jbehave</groupId>
<artifactId>jbehave-maven-plugin</artifactId>
<executions>
<execution>
<id>run-scenarios-found</id>
<phase>integration-test</phase>
<configuration>
<scenarioIncludes>
<scenarioInclude>${scenario.includes}</scenarioInclude>
</scenarioIncludes>
<scenarioExcludes>
<scenarioExclude>**/*Steps.java</scenarioExclude>
</scenarioExcludes>
<classLoaderInjected>false</classLoaderInjected>
</configuration>
<goals>
<goal>run-scenarios</goal>
</goals>
</execution>
</executions>
</plugin>

In this case Maven doesn't injects configuration parameters (see including and excluding below):

[INFO] [jbehave:run-scenarios {execution: default-cli}]
[DEBUG] Searching for scenario class names including null and excluding null
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Invalid scenario class path .svn\all-wcprops
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.jbehave.scenario.errors.InvalidScenarioClassPathException: Invalid scenario class path .svn\all-wcprops
at org.jbehave.scenario.parser.ScenarioClassNameFinder.classNameFor(ScenarioClassNameFinder.java:53)
at org.jbehave.scenario.parser.ScenarioClassNameFinder.listScenarioClassNames(ScenarioClassNameFinder.java:41)

And it can be fixed by moving <configuration> from <execution> to <plugin> tag:

<plugin>
<groupId>org.jbehave</groupId>
<artifactId>jbehave-maven-plugin</artifactId>
<configuration>
<scenarioIncludes>
<scenarioInclude>${scenario.includes}</scenarioInclude>
</scenarioIncludes>
<scenarioExcludes>
<scenarioExclude>**/*Steps.java</scenarioExclude>
</scenarioExcludes>
<classLoaderInjected>false</classLoaderInjected>
</configuration>
<executions>
<execution>
<id>run-scenarios-found</id>
<phase>integration-test</phase>
<goals>
<goal>run-scenarios</goal>
</goals>
</execution>
</executions>
</plugin>

After this result of execution is the following:

[DEBUG] Searching for scenario class names including [**/scenario/*.java] and excluding [**/*Steps.java]
[DEBUG] Found scenario class names: []
[INFO] No scenarios to run.
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] JBehave Examples ...................................... SUCCESS [1.592s]
[INFO] JBehave Game of Life Example .......................... SUCCESS [0.015s]
[INFO] JBehave Game of Life Example Scenarios ................ SUCCESS [0.010s]
[INFO] JBehave Trader Example ................................ SUCCESS [0.031s]
[INFO] JBehave Trader Test Scope Example ..................... SUCCESS [0.004s]
[INFO] JBehave Noughts And Crosses Example ................... SUCCESS [0.011s]
[INFO] JBehave Noughts And Crosses Example Scenarios ......... SUCCESS [0.014s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL

Thanks for clarification. This seems to confirm that the issue is with the embedded Maven in the IDE.

Closing issue for now, as there is a workaround via a different configuration.

Hello,

I can reproduce that bug with my plugin configuration - even when moving <configuration> section in plugin section unless I add <includes> and <excludes> section in that configuration.
Moreover, my scenarii class names are not found with that configuration.

For details, please see my plugin configuration below:
<plugin>
<groupId>org.jbehave</groupId>
<artifactId>jbehave-maven-plugin</artifactId>
<version>${jbehave.maven.plugin.version}</version>
<!-- configuration moved from execution section to plugin section - see http://jira.codehaus.org/browse/JBEHAVE-207 -->
<configuration>
<scenarioIncludes>
<scenarioInclude>**/*CommonStoriesTest.java</scenarioInclude>
</scenarioIncludes>
<scenarioExcludes>
<scenarioExclude>**/*Steps.java</scenarioExclude>
</scenarioExcludes>
<includes>
<include>**/*all-wcprops</include>
</includes>
<excludes>
<exclude>**/*all-wcprops</exclude>
</excludes>
<metaFilters>
<metaFilter>+author *</metaFilter>
<metaFilter>-skip</metaFilter>
</metaFilters>
<systemProperties>
<property>
<name>java.awt.headless</name>
<value>false</value>
</property>
</systemProperties>
<ignoreFailureInStories>false</ignoreFailureInStories>
<ignoreFailureInView>false</ignoreFailureInView>
<batch>true</batch>
</configuration>
<executions>
<execution>
<id>run-stories-as-embeddables</id>
<phase>integration-test</phase>
<goals>
<goal>run-stories-as-embeddables</goal>
<goal>report-stepdocs</goal>
<goal>generate-stories-view</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
</dependency>
</dependencies>
</plugin>

Using maven 3.0.3 and jbehave-maven-plugin 3.5.3, I am able to reproduce the problem above. I am using the maven command line client, not the embedded eclipse maven.

The problem seems to manifest itself only with the maven "site" goal. In this case the configuration section appears to be more or less inherited from the maven-surefire-plugin configuration?? This is true at least for the includes and excludes. I have no idea how this can be, but it is pretty easy to verify.

An "mvn test" runs fine, with configuration data injected as expected.

I think this issue needs to be reopened and looked at, there is definitely something funny going on here.

Please open a new jira issue, and if possible add a mini project to reproduce problem.