[jbehave-dev] [jira] Updated: (JBEHAVE-472) Scenario steps should be not performed after a failure in a @BeforeScenario/Story
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-472: - Summary: Scenario steps should be not performed after a failure in a @BeforeScenario/Story (was: Scenario steps are being executed after a failure in a @BeforeScenario/Story ) Scenario steps should be not performed after a failure in a @BeforeScenario/Story -- Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 This is a regression in 3.3, as it was working up to 3.2. The trader failing_before_after.story verifies the correct behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-472) StoryRunner should manage state at scenario level
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-472: - Description: We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. was: This is a regression in 3.3, as it was working up to 3.2. The trader failing_before_after.story verifies the correct behaviour. Issue Type: Improvement (was: Bug) Summary: StoryRunner should manage state at scenario level (was: Scenario steps should be not performed after a failure in a @BeforeScenario/Story ) StoryRunner should manage state at scenario level - Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-473) Multi-threading is not aware of RunContext.givenStory
Multi-threading is not aware of RunContext.givenStory - Key: JBEHAVE-473 URL: http://jira.codehaus.org/browse/JBEHAVE-473 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Fix For: 3.4 Multi-threading is not aware of RunContext.givenStory. In case of a story with a GivenStory it will throw: Failed to run story org/jbehave/examples/trader/stories/trader_sells_all_stocks.story java.lang.RuntimeException: Delayed methods already invoked at org.jbehave.core.reporters.ConcurrentStoryReporter.invokeDelayed(ConcurrentStoryReporter.java:286) The StoryRunner should invoke the delayed methods according the givenStory flag of the RunContext. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-471) Show as pending in reports view scenarios and stories that contain pending steps or no steps
[ http://jira.codehaus.org/browse/JBEHAVE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-471. -- Resolution: Fixed The stories are now reported as pending if they contains scenarios, which in turn are pending if the contain pending steps. The pending stories and scenarios are reported both in the reports (using same colour coding of pending steps) and in the command-line execution. Show as pending in reports view scenarios and stories that contain pending steps or no steps Key: JBEHAVE-471 URL: http://jira.codehaus.org/browse/JBEHAVE-471 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 As suggested by Jonathan Woods on user list: It would be useful if (i) stories with no steps were reported as pending, and their constituent scenarios too (ii) stories with any pending steps were reported as pending, and their constituent scenarios too (iii) a run with any pending stories was itself reported as pending, even if it was also regarded as successful When I say 'reported as', I mean in the kind of end result you can see at target/jbehave/view/reports.html. In jbehave-trader-example, I tried adding a new story alongside the existing test stories, and of course it was reported, but as successful only - nothing to indicate there's no implementation as suggested in (i) above. This kind of behaviour would serve as a flag to keep the implementer honest and maintain the flow of top-down development: you've not implemented x if you've not implemented something x depends on. It would help keep story development and implementation in synch: if I make a modification to a story (or create a whole new story) and JBehave can tell me everywhere that implementation is pending, that's great. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-148) Auto-generate method stubs for pending steps with no parameters
[
http://jira.codehaus.org/browse/JBEHAVE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-148.
--
Resolution: Fixed
Auto-generate method stubs for pending steps with no parameters
---
Key: JBEHAVE-148
URL: http://jira.codehaus.org/browse/JBEHAVE-148
Project: JBehave
Issue Type: Improvement
Components: Core
Reporter: Mauro Talevi
Assignee: Mauro Talevi
Fix For: 3.4
Auto-generate method stubs with no parameters. The steps such as
Given there is a flight
And there is a customer
When the customer books the flight
Then the customer is shown on the manifest
would generate Java methods like this:
@Given(there is a flight)
@Pending
public void givenThereIsAFlight() {
}
@Given(there is a customer) // note 'Given', even though story line is 'And'
@Pending
public void givenThereIsACustomer() {
}
@When(the customer books the flight)
@Pending
public void whenTheCustomerBooksTheFlight() {
}
@Then(the customer is shown on the flight manifest)
@Pending
public void thenTheCustomerIsShownOnTheFlightManifest() {
}
If @Pending annotated methods are already matched the methods should not be
re-generated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-474) Pending step method generation fails with And steps
[
http://jira.codehaus.org/browse/JBEHAVE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263257#action_263257
]
Mauro Talevi commented on JBEHAVE-474:
--
Hi Jon,
I've added your scenario to the trader pending.story and the problem cannot be
reproduced, i.e. And steps are well-handled.
From the stacktrace the problem is most probably with your configuration,
possibly of the keywords. It seems the for some reason the And keyword or
step type is not found.
Can you please provide a little self-contained project that reproduces the
problem? Something as simple as the pom.xml and the Stories class and the
.story file that you are using.
Pending step method generation fails with And steps
---
Key: JBEHAVE-474
URL: http://jira.codehaus.org/browse/JBEHAVE-474
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.1, 3.4
Environment: JDK 1.6.0_24 on Mac OS Snow Leopard
Reporter: Jonathan Woods
Priority: Minor
When I run over a scenario with 'and' steps, pending method generation fails.
The same scenario without the 'and' steps generates methods without any
problem (and is jolly useful).
The failure happens in 3.3.1 and in 3.4-SNAPSHOT, commit c27f34.
The failure results from an NPE; JBehave knows the story has failed, but the
run times out and then exits with 'pass' from the JUnit POV. Is that the
expected behaviour, btw?
Failing scenario:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in
And I have been redirected from my intended page to the login page
When I log in with good credentials
Then I am redirected to my intended page
And I am logged in
Console output:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in (PENDING)
And I have been redirected from my intended page to the login page (PENDING)
When I log in with good credentials (PENDING)
Then I am redirected to my intended page (PENDING)
And I am logged in (PENDING)
Failed to run story
package.name.here/login/i_can_log_in_with_correct_credentials.story
java.lang.NullPointerException
at
org.jbehave.core.steps.PendingStepMethodGenerator.stepStartsWithWord(PendingStepMethodGenerator.java:86)
at
org.jbehave.core.steps.PendingStepMethodGenerator.findStepType(PendingStepMethodGenerator.java:64)
at
org.jbehave.core.steps.PendingStepMethodGenerator.generateMethod(PendingStepMethodGenerator.java:32)
at
org.jbehave.core.embedder.StoryRunner.generatePendingStepMethods(StoryRunner.java:287)
at
org.jbehave.core.embedder.StoryRunner.runScenarioSteps(StoryRunner.java:272)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:170)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:95)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:686)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Story package.name.here/login/i_can_log_in_with_correct_credentials.story has
timed out after 61 seconds
Generating reports view to
'/Users/jonathanwoods/Documents/workspaces/main/mobile/target/jbehave' using
formats '[stats, console, txt, html, xml]' and view properties
'{decorateNonHtml=true}'
Reports view generated with 5 stories (of which 2 pending) containing 3
scenarios (of which 0 failed and 3 pending)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-474) Pending step method generation fails with And steps
[
http://jira.codehaus.org/browse/JBEHAVE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-474:
-
Comment: was deleted
(was: Hi Jon,
I've added your scenario to the trader pending.story and the problem cannot be
reproduced, i.e. And steps are well-handled.
From the stacktrace the problem is most probably with your configuration,
possibly of the keywords. It seems the for some reason the And keyword or
step type is not found.
Can you please provide a little self-contained project that reproduces the
problem? Something as simple as the pom.xml and the Stories class and the
.story file that you are using.
)
Pending step method generation fails with And steps
---
Key: JBEHAVE-474
URL: http://jira.codehaus.org/browse/JBEHAVE-474
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.1, 3.4
Environment: JDK 1.6.0_24 on Mac OS Snow Leopard
Reporter: Jonathan Woods
Priority: Minor
When I run over a scenario with 'and' steps, pending method generation fails.
The same scenario without the 'and' steps generates methods without any
problem (and is jolly useful).
The failure happens in 3.3.1 and in 3.4-SNAPSHOT, commit c27f34.
The failure results from an NPE; JBehave knows the story has failed, but the
run times out and then exits with 'pass' from the JUnit POV. Is that the
expected behaviour, btw?
Failing scenario:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in
And I have been redirected from my intended page to the login page
When I log in with good credentials
Then I am redirected to my intended page
And I am logged in
Console output:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in (PENDING)
And I have been redirected from my intended page to the login page (PENDING)
When I log in with good credentials (PENDING)
Then I am redirected to my intended page (PENDING)
And I am logged in (PENDING)
Failed to run story
package.name.here/login/i_can_log_in_with_correct_credentials.story
java.lang.NullPointerException
at
org.jbehave.core.steps.PendingStepMethodGenerator.stepStartsWithWord(PendingStepMethodGenerator.java:86)
at
org.jbehave.core.steps.PendingStepMethodGenerator.findStepType(PendingStepMethodGenerator.java:64)
at
org.jbehave.core.steps.PendingStepMethodGenerator.generateMethod(PendingStepMethodGenerator.java:32)
at
org.jbehave.core.embedder.StoryRunner.generatePendingStepMethods(StoryRunner.java:287)
at
org.jbehave.core.embedder.StoryRunner.runScenarioSteps(StoryRunner.java:272)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:170)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:95)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:686)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Story package.name.here/login/i_can_log_in_with_correct_credentials.story has
timed out after 61 seconds
Generating reports view to
'/Users/jonathanwoods/Documents/workspaces/main/mobile/target/jbehave' using
formats '[stats, console, txt, html, xml]' and view properties
'{decorateNonHtml=true}'
Reports view generated with 5 stories (of which 2 pending) containing 3
scenarios (of which 0 failed and 3 pending)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-474) Pending step method generation fails with And steps
[
http://jira.codehaus.org/browse/JBEHAVE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263258#action_263258
]
Mauro Talevi commented on JBEHAVE-474:
--
Hi Jon,
I've added your scenario to the trader pending.story and the problem cannot be
reproduced, i.e. And steps are well-handled.
From the stacktrace the problem is most probably with your configuration,
possibly of the keywords. It seems the for some reason the And keyword or
step type is not found.
Can you please provide a little self-contained project that reproduces the
problem? Something as simple as the pom.xml and the Stories class and the
.story file that you are using.
Pending step method generation fails with And steps
---
Key: JBEHAVE-474
URL: http://jira.codehaus.org/browse/JBEHAVE-474
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.1, 3.4
Environment: JDK 1.6.0_24 on Mac OS Snow Leopard
Reporter: Jonathan Woods
Priority: Minor
When I run over a scenario with 'and' steps, pending method generation fails.
The same scenario without the 'and' steps generates methods without any
problem (and is jolly useful).
The failure happens in 3.3.1 and in 3.4-SNAPSHOT, commit c27f34.
The failure results from an NPE; JBehave knows the story has failed, but the
run times out and then exits with 'pass' from the JUnit POV. Is that the
expected behaviour, btw?
Failing scenario:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in
And I have been redirected from my intended page to the login page
When I log in with good credentials
Then I am redirected to my intended page
And I am logged in
Console output:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in (PENDING)
And I have been redirected from my intended page to the login page (PENDING)
When I log in with good credentials (PENDING)
Then I am redirected to my intended page (PENDING)
And I am logged in (PENDING)
Failed to run story
package.name.here/login/i_can_log_in_with_correct_credentials.story
java.lang.NullPointerException
at
org.jbehave.core.steps.PendingStepMethodGenerator.stepStartsWithWord(PendingStepMethodGenerator.java:86)
at
org.jbehave.core.steps.PendingStepMethodGenerator.findStepType(PendingStepMethodGenerator.java:64)
at
org.jbehave.core.steps.PendingStepMethodGenerator.generateMethod(PendingStepMethodGenerator.java:32)
at
org.jbehave.core.embedder.StoryRunner.generatePendingStepMethods(StoryRunner.java:287)
at
org.jbehave.core.embedder.StoryRunner.runScenarioSteps(StoryRunner.java:272)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:170)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:95)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:686)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Story package.name.here/login/i_can_log_in_with_correct_credentials.story has
timed out after 61 seconds
Generating reports view to
'/Users/jonathanwoods/Documents/workspaces/main/mobile/target/jbehave' using
formats '[stats, console, txt, html, xml]' and view properties
'{decorateNonHtml=true}'
Reports view generated with 5 stories (of which 2 pending) containing 3
scenarios (of which 0 failed and 3 pending)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-474) Pending step method generation fails with And steps
[
http://jira.codehaus.org/browse/JBEHAVE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-474:
-
Fix Version/s: 3.4
Pending step method generation fails with And steps
---
Key: JBEHAVE-474
URL: http://jira.codehaus.org/browse/JBEHAVE-474
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.1
Environment: JDK 1.6.0_24 on Mac OS Snow Leopard
Reporter: Jonathan Woods
Assignee: Mauro Talevi
Priority: Minor
Fix For: 3.4, 3.3.2
When I run over a scenario with 'and' steps, pending method generation fails.
The same scenario without the 'and' steps generates methods without any
problem (and is jolly useful).
The failure happens in 3.3.1 and in 3.4-SNAPSHOT, commit c27f34.
The failure results from an NPE; JBehave knows the story has failed, but the
run times out and then exits with 'pass' from the JUnit POV. Is that the
expected behaviour, btw?
Failing scenario:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in
And I have been redirected from my intended page to the login page
When I log in with good credentials
Then I am redirected to my intended page
And I am logged in
Console output:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in (PENDING)
And I have been redirected from my intended page to the login page (PENDING)
When I log in with good credentials (PENDING)
Then I am redirected to my intended page (PENDING)
And I am logged in (PENDING)
Failed to run story
package.name.here/login/i_can_log_in_with_correct_credentials.story
java.lang.NullPointerException
at
org.jbehave.core.steps.PendingStepMethodGenerator.stepStartsWithWord(PendingStepMethodGenerator.java:86)
at
org.jbehave.core.steps.PendingStepMethodGenerator.findStepType(PendingStepMethodGenerator.java:64)
at
org.jbehave.core.steps.PendingStepMethodGenerator.generateMethod(PendingStepMethodGenerator.java:32)
at
org.jbehave.core.embedder.StoryRunner.generatePendingStepMethods(StoryRunner.java:287)
at
org.jbehave.core.embedder.StoryRunner.runScenarioSteps(StoryRunner.java:272)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:170)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:95)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:686)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Story package.name.here/login/i_can_log_in_with_correct_credentials.story has
timed out after 61 seconds
Generating reports view to
'/Users/jonathanwoods/Documents/workspaces/main/mobile/target/jbehave' using
formats '[stats, console, txt, html, xml]' and view properties
'{decorateNonHtml=true}'
Reports view generated with 5 stories (of which 2 pending) containing 3
scenarios (of which 0 failed and 3 pending)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-474) Pending step method generation fails with And steps
[
http://jira.codehaus.org/browse/JBEHAVE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-474.
--
Resolution: Fixed
Mystery solved: the problem manifested itself only if there are no step
candidates, i.e. no annotated methods in your Steps class.
In any case, the mechanism to look for the previous non-And step has now been
refactored to not depend on the presence of step candidates.
Pending step method generation fails with And steps
---
Key: JBEHAVE-474
URL: http://jira.codehaus.org/browse/JBEHAVE-474
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.1
Environment: JDK 1.6.0_24 on Mac OS Snow Leopard
Reporter: Jonathan Woods
Assignee: Mauro Talevi
Priority: Minor
Fix For: 3.4, 3.3.2
When I run over a scenario with 'and' steps, pending method generation fails.
The same scenario without the 'and' steps generates methods without any
problem (and is jolly useful).
The failure happens in 3.3.1 and in 3.4-SNAPSHOT, commit c27f34.
The failure results from an NPE; JBehave knows the story has failed, but the
run times out and then exits with 'pass' from the JUnit POV. Is that the
expected behaviour, btw?
Failing scenario:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in
And I have been redirected from my intended page to the login page
When I log in with good credentials
Then I am redirected to my intended page
And I am logged in
Console output:
Scenario: When I log in with good credentials after having been redirected to
the login page from my intended page, I am redirected to my intended page
Given I am not logged in (PENDING)
And I have been redirected from my intended page to the login page (PENDING)
When I log in with good credentials (PENDING)
Then I am redirected to my intended page (PENDING)
And I am logged in (PENDING)
Failed to run story
package.name.here/login/i_can_log_in_with_correct_credentials.story
java.lang.NullPointerException
at
org.jbehave.core.steps.PendingStepMethodGenerator.stepStartsWithWord(PendingStepMethodGenerator.java:86)
at
org.jbehave.core.steps.PendingStepMethodGenerator.findStepType(PendingStepMethodGenerator.java:64)
at
org.jbehave.core.steps.PendingStepMethodGenerator.generateMethod(PendingStepMethodGenerator.java:32)
at
org.jbehave.core.embedder.StoryRunner.generatePendingStepMethods(StoryRunner.java:287)
at
org.jbehave.core.embedder.StoryRunner.runScenarioSteps(StoryRunner.java:272)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:170)
at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:95)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:686)
at
org.jbehave.core.embedder.Embedder$EnqueuedStory.call(Embedder.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Story package.name.here/login/i_can_log_in_with_correct_credentials.story has
timed out after 61 seconds
Generating reports view to
'/Users/jonathanwoods/Documents/workspaces/main/mobile/target/jbehave' using
formats '[stats, console, txt, html, xml]' and view properties
'{decorateNonHtml=true}'
Reports view generated with 5 stories (of which 2 pending) containing 3
scenarios (of which 0 failed and 3 pending)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-355) Groovy bindings for steps
[ http://jira.codehaus.org/browse/JBEHAVE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-355. -- Resolution: Duplicate Duplicate of JBEHAVE-365. Groovy bindings for steps - Key: JBEHAVE-355 URL: http://jira.codehaus.org/browse/JBEHAVE-355 Project: JBehave Issue Type: Improvement Components: Core Reporter: Paul Hammant Adriano Bonat (ThoughtWorker) suggests that invoking step methods written in Groovy would be cool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-476) Archetypes to boostrap creation of projects
Archetypes to boostrap creation of projects --- Key: JBEHAVE-476 URL: http://jira.codehaus.org/browse/JBEHAVE-476 Project: JBehave Issue Type: New Feature Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 Archetypes are a useful way to help projects bootstrap their testing setup. Maven natively supports the concept of archetypes, which are templates used to generate new projects. The archetype resources are Velocity templates packaged as a jar. Maven provides a META-INF/maven/archetype-descriptor.xml, but other tools can still use the archetype resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-476) Archetypes to boostrap creation of projects
[ http://jira.codehaus.org/browse/JBEHAVE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-476 started by Mauro Talevi. Archetypes to boostrap creation of projects --- Key: JBEHAVE-476 URL: http://jira.codehaus.org/browse/JBEHAVE-476 Project: JBehave Issue Type: New Feature Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 Archetypes are a useful way to help projects bootstrap their testing setup. Maven natively supports the concept of archetypes, which are templates used to generate new projects. The archetype resources are Velocity templates packaged as a jar. Maven provides a META-INF/maven/archetype-descriptor.xml, but other tools can still use the archetype resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-424) Test run with Eclipse but no with maven
[ http://jira.codehaus.org/browse/JBEHAVE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263447#action_263447 ] Mauro Talevi commented on JBEHAVE-424: -- The problem seems to suggest you're not adding the applicationContext.xml as a resource and therefore it never gets added to the classpath. To verify that this is the case simply look in target/classes after you've done a Maven build and see it the file is there. If not, configure your POM resources to add it. There are plenty of examples, e.g. a Spring security one, that may help you (http://jbehave.org/reference/stable/examples-philosophy.html). Test run with Eclipse but no with maven --- Key: JBEHAVE-424 URL: http://jira.codehaus.org/browse/JBEHAVE-424 Project: JBehave Issue Type: Bug Components: Maven Plugin Affects Versions: 3.1.2 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) Java version: 1.6.0_04 Java home: C:\Archivos de programa\Java\jdk1.6.0_04\jre Default locale: es_AR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Gardella Juan Pablo Attachments: sample.zip I want to integrate Jbehave with maven and have a lot of troubles. I attach a sample with an example. The Story pass if I run as Junit test in eclipse, but when I try with maven fail. Is a classloader problem. The exception is: org.springframework.beans.factory.BeanDefinitionStoreException: IOException pars ing XML document from class path resource [applicationContext.xml]; nested excep tion is java.io.FileNotFoundException: class path resource [applicationContext.x ml] cannot be opened because it does not exist But to fix this I must pass ALL dependencies to the plugin. I hope there is a solution to this. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-478) Add localization for zh_TW
[ http://jira.codehaus.org/browse/JBEHAVE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-478: - Fix Version/s: 3.4 Assignee: Mauro Talevi Add localization for zh_TW -- Key: JBEHAVE-478 URL: http://jira.codehaus.org/browse/JBEHAVE-478 Project: JBehave Issue Type: Improvement Components: Core Reporter: Poyi Wu Assignee: Mauro Talevi Fix For: 3.4 Attachments: keywords_zh_TW.properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-479) Cross Reference XM/JSON should include meta-filter choice (if present) for display in Story Navigator output
[ http://jira.codehaus.org/browse/JBEHAVE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-479: - Fix Version/s: 3.4 Issue Type: Improvement (was: New Feature) Cross Reference XM/JSON should include meta-filter choice (if present) for display in Story Navigator output Key: JBEHAVE-479 URL: http://jira.codehaus.org/browse/JBEHAVE-479 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3.2 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-149) Support loading of stories from ODT format
[ http://jira.codehaus.org/browse/JBEHAVE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-149: - Component/s: ODT Support Description: As a BA I want to be able to write my story in a ODT format (was: As a BA I want to be able to write my scenario in a non-textual format, e.g. spreadsheet, and convert to and from textual format.) Fix Version/s: 3.4 Assignee: Mauro Talevi Summary: Support loading of stories from ODT format (was: Support conversion of scenarios from non-textual formats) Support loading of stories from ODT format -- Key: JBEHAVE-149 URL: http://jira.codehaus.org/browse/JBEHAVE-149 Project: JBehave Issue Type: New Feature Components: ODT Support Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 As a BA I want to be able to write my story in a ODT format -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-149) Support loading of stories from ODT format
[ http://jira.codehaus.org/browse/JBEHAVE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-149. -- Resolution: Fixed Started with ODT format support. Other formats like ODS can be added later in the same jbehave-odf module. Support loading of stories from ODT format -- Key: JBEHAVE-149 URL: http://jira.codehaus.org/browse/JBEHAVE-149 Project: JBehave Issue Type: New Feature Components: ODF Support Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 As a BA I want to be able to write my story in a ODT format -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-480) Add settings.xml to the bin distribution
Add settings.xml to the bin distribution Key: JBEHAVE-480 URL: http://jira.codehaus.org/browse/JBEHAVE-480 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 As suggested by Andreas Havenstein, it's useful to have the settings.xml added to the bin distro. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-480) Add settings.xml to the bin distribution
[ http://jira.codehaus.org/browse/JBEHAVE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-480. -- Resolution: Fixed Add settings.xml to the bin distribution Key: JBEHAVE-480 URL: http://jira.codehaus.org/browse/JBEHAVE-480 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 As suggested by Andreas Havenstein, it's useful to have the settings.xml added to the bin distro. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Reopened: (JBEHAVE-482) Improve handling of Saucelabs auth errors.
[ http://jira.codehaus.org/browse/JBEHAVE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-482: -- Improve handling of Saucelabs auth errors. -- Key: JBEHAVE-482 URL: http://jira.codehaus.org/browse/JBEHAVE-482 Project: JBehave Issue Type: Bug Affects Versions: web-3.3 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: web-3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-472) Improve state management of StoryRunner
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-472: - Summary: Improve state management of StoryRunner (was: StoryRunner should manage state at scenario level) Improve state management of StoryRunner --- Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-472) StoryRunner should manage state at scenario level
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-472 started by Mauro Talevi. StoryRunner should manage state at scenario level - Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-472) Improve state management of StoryRunner
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-472. -- Resolution: Fixed Improve state management of StoryRunner --- Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd behaviours when there are failure in the @Before steps but not in the normal steps. Examples of such a behaviour are the trader failing_before_after.story and failing_before_stories.story. A better and more intuitive state management should be in place, keeping state in the run context. The state should be reset by default before each scenario (to ensure backward compat) but will be shared between the @Before/@After steps and the normal steps. We should also have the option to not reset it before each scenario to allow for failures in the @BeforeStory/Stories steps to propagate to the scenario steps in the same run context. Once a failing state in a given run context, the steps that follow will not be performed, as customary with normal steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-484) Upgrade to latest released version of build plugins
[ http://jira.codehaus.org/browse/JBEHAVE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-484. -- Resolution: Fixed Upgrade to latest released version of build plugins --- Key: JBEHAVE-484 URL: http://jira.codehaus.org/browse/JBEHAVE-484 Project: JBehave Issue Type: Task Components: Build Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-482) Initialisation errors in RemoteWebDriverProvider are not being reported
[ http://jira.codehaus.org/browse/JBEHAVE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-482. -- Resolution: Fixed Initialisation errors in RemoteWebDriverProvider are not being reported --- Key: JBEHAVE-482 URL: http://jira.codehaus.org/browse/JBEHAVE-482 Project: JBehave Issue Type: Bug Affects Versions: web-3.3 Reporter: Paul Hammant Assignee: Paul Hammant Fix For: web-3.3.1 Errors in initialize() method in RemoteWebDriverProvider (e.g. due to auth failure in SauceWebDriverProvider) are not being reported. Added RemoteWebDriverProviderTest to verify behaviour (the missing URL should lead to a RunningStoriesFailed exception in the Embedder). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-487) Allow parameters to be specified as meta properties
Allow parameters to be specified as meta properties
---
Key: JBEHAVE-487
URL: http://jira.codehaus.org/browse/JBEHAVE-487
Project: JBehave
Issue Type: New Feature
Components: Core
Reporter: Mauro Talevi
Assignee: Mauro Talevi
Fix For: 3.4
As suggested by Paul, parameters may be specified as Meta properties:
{noformat}
Meta:
@theme parameters
Scenario:
Meta:
@variant named
Given I have specified the theme
And a variant
Then the theme is parameters with variant named
{noformat}
The named meta parameters would be matched by usual @Named mechanism, also used
in story or scenario parametrisation.
{code}
@Given(I have specified the theme)
public void givenIHaveSpecifiedTheTheme(@Named(theme) String theme){
this.theme = theme;
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-487) Allow parameters to be specified as meta properties
[
http://jira.codehaus.org/browse/JBEHAVE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JBEHAVE-487 started by Mauro Talevi.
Allow parameters to be specified as meta properties
---
Key: JBEHAVE-487
URL: http://jira.codehaus.org/browse/JBEHAVE-487
Project: JBehave
Issue Type: New Feature
Components: Core
Reporter: Mauro Talevi
Assignee: Mauro Talevi
Fix For: 3.4
As suggested by Paul, parameters may be specified as Meta properties:
{noformat}
Meta:
@theme parameters
Scenario:
Meta:
@variant named
Given I have specified the theme
And a variant
Then the theme is parameters with variant named
{noformat}
The named meta parameters would be matched by usual @Named mechanism, also
used in story or scenario parametrisation.
{code}
@Given(I have specified the theme)
public void givenIHaveSpecifiedTheTheme(@Named(theme) String theme){
this.theme = theme;
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-488) Scenario with nested or recursive example table
[
http://jira.codehaus.org/browse/JBEHAVE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264209#action_264209
]
Mauro Talevi commented on JBEHAVE-488:
--
This sounds like an interesting use case, but I would not use a meta property
to drive it. Rather, we could enhance the Examples: syntax. E.g.
Examples:
{foreach Page: Home, OrderFood, CheckStatus, CancelOrder}
... table as usual
The advantage is that we keep the parameters of the examples self-contained in
the ExamplesTable (which can parse the directives too)
Scenario with nested or recursive example table
---
Key: JBEHAVE-488
URL: http://jira.codehaus.org/browse/JBEHAVE-488
Project: JBehave
Issue Type: New Feature
Reporter: kk sure
We have a UI functionality that repeats on many pages (say it is a JSPF
component that is reusable, with configurable variation). But it is important
to test this on all pages since the functionality is slightly different on
each of these pages.
h2. How we have to code this today:
Scenario: Food widget in Home page
Given I am on Home page
When I enter food_item in the menu field
Then I see related_food_items in the dropdown
Examples:
|food_item|related_food_items|
|pizza|cheese, chicken, bacon|
|fruit_salad|mangoes, strawberry, grapes|
|rice|brown, white, fried|
The exact same test will repeat on a different page like below
Scenario: Food widget in OrderFood page
Given I am on OrderFood page
When I enter food_item in the menu field
Then I see related_food_items in the dropdown
Examples:
|food_item|related_food_items|
|pizza|cheese, chicken, bacon|
|fruit_salad|mangoes, strawberry, grapes|
|rice|brown, white, fried|
h2. Problem Statement: We want to run a particular scenario with 'examples'
over another parametrized value (e.g 'Page' here).
h2. Proposed solution: foreach meta-tag at scenario level that has processing
implications.
Scenario:
Meta:
@foreach Page: Home, OrderFood, CheckStatus, CancelOrder
Given I am on the Page page
When I enter food_item in the menu field
Then I see related_food_items in the dropdown
Examples:
|food_item|related_food_items|
|pizza|cheese, chicken, bacon|
|fruit_salad|mangoes, strawberry, grapes|
|rice|brown, white, fried|
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Reopened: (JBEHAVE-472) Improve state management of StoryRunner
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-472: -- The refactor has broken the failure UUID correlation between stories (JBEHAVE-490). Added FailureCorrelationStories in trader example to reproduce behaviour. Improve state management of StoryRunner --- Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd behaviours when there are failure in the @Before steps but not in the normal steps. Examples of such a behaviour are the trader failing_before_after.story and failing_before_stories.story. A better and more intuitive state management should be in place, keeping state in the run context. The state should be reset by default before each scenario (to ensure backward compat) but will be shared between the @Before/@After steps and the normal steps. We should also have the option to not reset it before each scenario to allow for failures in the @BeforeStory/Stories steps to propagate to the scenario steps in the same run context. Once a failing state in a given run context, the steps that follow will not be performed, as customary with normal steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-490) Screenshots for failing scenarios are taken but not correlated with the story HTML output hyperlink
[ http://jira.codehaus.org/browse/JBEHAVE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-490: - Description: This could well be an issue in core around exceptions being thrown (wrapped by UUIDExceptionWrapper). 1) Apply the attached patch to Etsy (it makes everything fail). 2) Run regular build (no saucelabs): mvn clean install 3) Open Navigator or reports page and click through to the HTML page for the failing story. 4) Click the screenshot icon (see that it 404s) 5) Otherwise check the screenshots directory, and observer that it has only one screenshot, instead of one for each failed story. was: This could well be an issue in core around exceptions being thrown (wrapped by UUIDExceptionWrapper). 1) Apply the attached patch to Etsy (it makes everything fail). 2) Run regular build (no saucelabs). 3) Open Navigator (or the older results page) and click through to the HTML page for the failing story. 4) Click the screen-shot icon (see that it 404s) 5) Otherwise check the screen-shots directory, and observer that it has three screenshots. Fix Version/s: web-3.4 Assignee: Mauro Talevi Summary: Screenshots for failing scenarios are taken but not correlated with the story HTML output hyperlink (was: Screen-shots for failing scenarios are being taken, but are not correlated with the story-results HTML output's hyperlink.) Screenshots for failing scenarios are taken but not correlated with the story HTML output hyperlink --- Key: JBEHAVE-490 URL: http://jira.codehaus.org/browse/JBEHAVE-490 Project: JBehave Issue Type: Bug Components: Web Selenium Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: web-3.4 Attachments: screenshots404.patch This could well be an issue in core around exceptions being thrown (wrapped by UUIDExceptionWrapper). 1) Apply the attached patch to Etsy (it makes everything fail). 2) Run regular build (no saucelabs): mvn clean install 3) Open Navigator or reports page and click through to the HTML page for the failing story. 4) Click the screenshot icon (see that it 404s) 5) Otherwise check the screenshots directory, and observer that it has only one screenshot, instead of one for each failed story. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-490) Screenshots for failing scenarios are taken but not correlated with the story HTML output hyperlink
[ http://jira.codehaus.org/browse/JBEHAVE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264418#action_264418 ] Mauro Talevi commented on JBEHAVE-490: -- This is caused by JBEHAVE-472, fixed from core 3.4-beta-2. Screenshots for failing scenarios are taken but not correlated with the story HTML output hyperlink --- Key: JBEHAVE-490 URL: http://jira.codehaus.org/browse/JBEHAVE-490 Project: JBehave Issue Type: Bug Components: Web Selenium Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: web-3.4 Attachments: screenshots404.patch This could well be an issue in core around exceptions being thrown (wrapped by UUIDExceptionWrapper). 1) Apply the attached patch to Etsy (it makes everything fail). 2) Run regular build (no saucelabs): mvn clean install 3) Open Navigator or reports page and click through to the HTML page for the failing story. 4) Click the screenshot icon (see that it 404s) 5) Otherwise check the screenshots directory, and observer that it has only one screenshot, instead of one for each failed story. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-486) Firefox window not closing (by default) when failure occurs
[ http://jira.codehaus.org/browse/JBEHAVE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-486: - Fix Version/s: web-3.4 Assignee: Mauro Talevi Summary: Firefox window not closing (by default) when failure occurs (was: Firefox window not closing (by default) for JB run with failure in it.) Firefox window not closing (by default) when failure occurs --- Key: JBEHAVE-486 URL: http://jira.codehaus.org/browse/JBEHAVE-486 Project: JBehave Issue Type: Bug Components: Web Selenium Affects Versions: web-3.3.1 Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: web-3.4 Steps to reproduce for Etsy: 1) Corrupt CartContents.goovy (line 24) like so aim at an xpath like so: findElement(By.xpath(//a[@rel = 'removeee'])).click() 2) Run the build. 3) Note that there is a Firefox window open at the end of the run. This did not happen before the 3.4-beta-1 (core) and 3.3.1 (web) releases :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-486) Firefox window not closing (by default) when failure occurs
[ http://jira.codehaus.org/browse/JBEHAVE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264466#action_264466 ] Mauro Talevi commented on JBEHAVE-486: -- Root cause is JBEHAVE-472. Fixed in 3.4-beta-2. Firefox window not closing (by default) when failure occurs --- Key: JBEHAVE-486 URL: http://jira.codehaus.org/browse/JBEHAVE-486 Project: JBehave Issue Type: Bug Components: Web Selenium Affects Versions: web-3.3.1 Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: web-3.4 Steps to reproduce for Etsy: 1) Corrupt CartContents.goovy (line 24) like so aim at an xpath like so: findElement(By.xpath(//a[@rel = 'removeee'])).click() 2) Run the build. 3) Note that there is a Firefox window open at the end of the run. This did not happen before the 3.4-beta-1 (core) and 3.3.1 (web) releases :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-491: - Summary: Add JBehave Spring Namespace support for easier configuration (was: Implements JBehave Spring Namespace for easier integration between JBehave and Spring) Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Affects Versions: 3.x Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.4 I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-491 started by Mauro Talevi. Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Affects Versions: 3.x Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.4 I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264467#action_264467 ] Mauro Talevi commented on JBEHAVE-491: -- Hi Alex, thanks for the very good contribution. I've pulled it in master. A couple of comments: - wouldn't the schema be more appropriately called jbehave rather than embedder - ditto when the registering of the bean definition parser What is not quite clear is your goal, i.e. you want to provide a namespaced version of the normal spring configuration or to just allow the construction of the embedder. It's be very useful if you could also provide a unit-level behaviour that clarified your intent. You could start from SpringAnnotationBuilderBehaviour as a based for you SpringNamespaceConfigurationBehaviour. Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Affects Versions: 3.x Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.4 I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264480#action_264480 ] Mauro Talevi commented on JBEHAVE-491: -- Yes, I agree, but that is not what I meant. I've pushed some minor renames. The schema is now called jbehave-spring-1.0.xsd and lives in url http://jbehave.org/schemas/spring. Within the same schema we can define multiple elements, Embedder being one of them. And if you could add a unit test that tests all this it would help to test the schema in isolation and communicate better the intend of what you've developed. Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Affects Versions: 3.x Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.4 I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Fix Version/s: 3.x
Issue Type: New Feature (was: Bug)
Summary: ConfigurableEmbedder.addSteps(..) should take classes not
instances. (was: ConfigurableSteps.addSteps(..) should take classes not
instances.)
ConfigurableEmbedder.addSteps(..) should take classes not instances.
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Fix For: 3.x
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that instance is
**never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this instance is going to be garbage collected and never
used, and (b) on SauceLabs at least it would result in browser opening in the
cloud then closing (or maybe not closing, but never used; I'm not sure).
JBehave does not actually need the instance. I believe this is provable.
Instead it could perfectly well use the class definition without the instance
ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Paul, why do you say the instance of a steps class is never used? How are the
methods executed?
And as Brian was rightfully noting, how would DI work?
Isn't your usecase too influenced by the use of Groovy to drive WebDriver?
ConfigurableEmbedder.addSteps(..) should take classes not instances.
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Fix For: 3.x
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that instance is
**never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this instance is going to be garbage collected and never
used, and (b) on SauceLabs at least it would result in browser opening in the
cloud then closing (or maybe not closing, but never used; I'm not sure).
JBehave does not actually need the instance. I believe this is provable.
Instead it could perfectly well use the class definition without the instance
ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264715#action_264715
]
Mauro Talevi commented on JBEHAVE-492:
--
Sorry, still no wiser about this use case :-( What do you mean by initial
instance?
ConfigurableEmbedder.addSteps(..) should take classes not instances.
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Fix For: 3.x
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage
collected and never used, and (b) on SauceLabs at least it would result in
browser opening in the cloud then closing (or maybe not closing, but never
used; I'm not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without
the instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=264726#action_264726
]
Mauro Talevi commented on JBEHAVE-492:
--
So when are the steps classes instantiated when running in SauceLabs? Is this
specific to the use of Groovy (effectively you're using a default constructor
and GrooBe to autowire your pages) or generic for all Java classes?
ConfigurableEmbedder.addSteps(..) should take classes not instances.
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Fix For: 3.x
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage
collected and never used, and (b) on SauceLabs at least it would result in
browser opening in the cloud then closing (or maybe not closing, but never
used; I'm not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without
the instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-494) Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields.
[ http://jira.codehaus.org/browse/JBEHAVE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-494: - Fix Version/s: (was: 3.4) web-3.4 Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields. -- Key: JBEHAVE-494 URL: http://jira.codehaus.org/browse/JBEHAVE-494 Project: JBehave Issue Type: Improvement Components: Web Selenium Reporter: Paul Hammant Assignee: Paul Hammant Fix For: web-3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-493) Split Firefox logic out of generic Type provider and into own class.
[ http://jira.codehaus.org/browse/JBEHAVE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-493: - Fix Version/s: (was: 3.4) web-3.4 Split Firefox logic out of generic Type provider and into own class. Key: JBEHAVE-493 URL: http://jira.codehaus.org/browse/JBEHAVE-493 Project: JBehave Issue Type: Improvement Components: Web Selenium Reporter: Paul Hammant Assignee: Paul Hammant Fix For: web-3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Summary: CandidateSteps instances should be created by StoryRunner context
allowing for multi-threaded stateful steps logic (was:
ConfigurableEmbedder.addSteps(..) should take classes not instances.)
CandidateSteps instances should be created by StoryRunner context allowing
for multi-threaded stateful steps logic
--
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Fix For: 3.x
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage
collected and never used, and (b) on SauceLabs at least it would result in
browser opening in the cloud then closing (or maybe not closing, but never
used; I'm not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without
the instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-495) Upgrade Groovy dependency to 1.8.0
[ http://jira.codehaus.org/browse/JBEHAVE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-495. -- Resolution: Fixed Upgrade Groovy dependency to 1.8.0 -- Key: JBEHAVE-495 URL: http://jira.codehaus.org/browse/JBEHAVE-495 Project: JBehave Issue Type: Task Components: Groovy Support Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-495) Upgrade Groovy dependency to 1.8.0
[ http://jira.codehaus.org/browse/JBEHAVE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-495: - Priority: Minor (was: Major) Issue Type: Task (was: Improvement) Upgrade Groovy dependency to 1.8.0 -- Key: JBEHAVE-495 URL: http://jira.codehaus.org/browse/JBEHAVE-495 Project: JBehave Issue Type: Task Components: Groovy Support Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-487) Allow parameters to be specified as meta properties
[
http://jira.codehaus.org/browse/JBEHAVE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-487.
--
Resolution: Fixed
Allow parameters to be specified as meta properties
---
Key: JBEHAVE-487
URL: http://jira.codehaus.org/browse/JBEHAVE-487
Project: JBehave
Issue Type: New Feature
Components: Core
Reporter: Mauro Talevi
Assignee: Mauro Talevi
Fix For: 3.4
As suggested by Paul, parameters may be specified as Meta properties:
{noformat}
Meta:
@theme parameters
Scenario:
Meta:
@variant named
Given I have specified the theme
And a variant
Then the theme is parameters with variant named
{noformat}
The named meta parameters would be matched by usual @Named mechanism, also
used in story or scenario parametrisation.
{code}
@Given(I have specified the theme)
public void givenIHaveSpecifiedTheTheme(@Named(theme) String theme){
this.theme = theme;
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-496) Null meta filters should be ignored in Maven plugin
Null meta filters should be ignored in Maven plugin --- Key: JBEHAVE-496 URL: http://jira.codehaus.org/browse/JBEHAVE-496 Project: JBehave Issue Type: Improvement Components: Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 When specifying the meta filters via the Maven plugin, null entries are sometimes passed in, which should be ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Fix Version/s: (was: 3.x)
3.4
Assignee: Mauro Talevi
CandidateSteps instances should be created by StoryRunner context allowing
for multi-threaded stateful steps logic
--
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Assignee: Mauro Talevi
Fix For: 3.4
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage
collected and never used, and (b) on SauceLabs at least it would result in
browser opening in the cloud then closing (or maybe not closing, but never
used; I'm not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without
the instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with
CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Description:
In multi-threaded mode, the steps instances need to be instantiated per thread.
A way to do this is to pass the InjectableStepsFactory to the StoryRunner run
context and let the context instantiate the candidate steps per thread.
was:
public void addSteps(ListClass steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage collected
and never used, and (b) on SauceLabs at least it would result in browser
opening in the cloud then closing (or maybe not closing, but never used; I'm
not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without the
instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with CandidateSteps,
and use the POJO Step's class-def directly.
CandidateSteps instances should be created by StoryRunner context allowing
for multi-threaded stateful steps logic
--
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: New Feature
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
Assignee: Mauro Talevi
Fix For: 3.4
In multi-threaded mode, the steps instances need to be instantiated per
thread.
A way to do this is to pass the InjectableStepsFactory to the StoryRunner run
context and let the context instantiate the candidate steps per thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-498) withRelativeDirectory appears to be broken
[
http://jira.codehaus.org/browse/JBEHAVE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265426#action_265426
]
Mauro Talevi commented on JBEHAVE-498:
--
The relativeDirectory is the directory where the JBehave reporting outputs are
written to (defaults to jbehave), relative to the story builder code location
(defaults to CodeLocations.codeLocationFromPath(target/classes)).
If you change the relative directory and you're not using the Maven standard
layout, you'll probably need to set the code location accordingly, e.g.
CodeLocations.codeLocationFromPath(build/publish) and
withRelativeDirectory(story-reports), or combinations thereof.
You could also try seting the code location from the JUnitStories class:
CodeLocations.codeLocationFromClass(this.getClass());
withRelativeDirectory appears to be broken
--
Key: JBEHAVE-498
URL: http://jira.codehaus.org/browse/JBEHAVE-498
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: web-3.3
Environment: Linux. Jdk6
Reporter: Derek Clarkson
I'm working in a non maven environment. I attempted to set the output
directory for reports as follows
public static class MyReportBuilder extends StoryReporterBuilder {
public MyReportBuilder() {
super();
this.withRelativeDirectory(../build/publish/story-reports);
this.withFormats(CONSOLE, HTML, XML);
}
}
Upon running the JUnits I get the following:
org.jbehave.core.reporters.FilePrintStreamFactory$PrintStreamCreationFailed:
Failed to create print stream for file
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
at
org.jbehave.core.reporters.FilePrintStreamFactory.createPrintStream(FilePrintStreamFactory.java:39)
at
org.jbehave.core.reporters.Format$4.createStoryReporter(Format.java:43)
at
org.jbehave.core.reporters.StoryReporterBuilder.reporterFor(StoryReporterBuilder.java:310)
at
org.jbehave.core.reporters.StoryReporterBuilder.build(StoryReporterBuilder.java:285)
at
org.jbehave.core.configuration.Configuration.storyReporter(Configuration.java:200)
at
org.jbehave.core.embedder.StoryRunner.runBeforeOrAfterStories(StoryRunner.java:58)
at
org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:209)
at
au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder.run(AnnotatedStoryEmbedder.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.FileNotFoundException:
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
(No such file or directory)
at
[jbehave-dev] [jira] Created: (JBEHAVE-499) Rename run-with-annotated-embedder goal to run-stories-with-annotated-embedder
Rename run-with-annotated-embedder goal to run-stories-with-annotated-embedder -- Key: JBEHAVE-499 URL: http://jira.codehaus.org/browse/JBEHAVE-499 Project: JBehave Issue Type: Improvement Components: Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 The goal name is inconsistent with the other goal names. For backward compat, we can keep the previous goal name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-499) Rename run-with-annotated-embedder goal to run-stories-with-annotated-embedder
[ http://jira.codehaus.org/browse/JBEHAVE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-499. -- Resolution: Fixed Rename run-with-annotated-embedder goal to run-stories-with-annotated-embedder -- Key: JBEHAVE-499 URL: http://jira.codehaus.org/browse/JBEHAVE-499 Project: JBehave Issue Type: Improvement Components: Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 The goal name is inconsistent with the other goal names. For backward compat, we can keep the previous goal name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-149) Support loading of stories from ODT format
[ http://jira.codehaus.org/browse/JBEHAVE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265516#action_265516 ] Mauro Talevi commented on JBEHAVE-149: -- Thanks, Bart. Patch applied. Support loading of stories from ODT format -- Key: JBEHAVE-149 URL: http://jira.codehaus.org/browse/JBEHAVE-149 Project: JBehave Issue Type: New Feature Components: ODF Support Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 Attachments: jbehave-odf-with-table.zip As a BA I want to be able to write my story in a ODT format -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-502) Add installation instructions to website documentation
[ http://jira.codehaus.org/browse/JBEHAVE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265548#action_265548 ] Mauro Talevi commented on JBEHAVE-502: -- Derek, in the lib directory binary distribution there is an Ant script with a target to copy all the dependencies using the latest up-to-date POM (c.f. the docs/dependencies.html). The Maven POM provides the meta-info about the dependencies, which can then be interpreted by the tool used for dependency management, Ivy or Maven Ant Tasks. Add installation instructions to website documentation -- Key: JBEHAVE-502 URL: http://jira.codehaus.org/browse/JBEHAVE-502 Project: JBehave Issue Type: Improvement Components: Core Reporter: Derek Clarkson I've been scouring the site for a couple of days trying to figure out what I needed to install and where. I'm not using maven. The website doesn't give any idea of how to setup JBehave when not in a maven environment. So I'm having to do it by reverse engineering the maven pom. The first problem was to trying and figure out what to download. The linked download file is only of use in a maven world. So I had to start downloaded by surfing the online repos. So I'd suggest that the raw jars and zips should also be linked for download from the main site. The second issue was what to unzip, etc and suggested directories. Again the documentation takes a it will just work approach, which it doesn't. So instructions are needed here to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-501) Report stying not being generated
[
http://jira.codehaus.org/browse/JBEHAVE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265549#action_265549
]
Mauro Talevi commented on JBEHAVE-501:
--
The trader example has an Ant build script that you can use as a template to
get you started. It downloads the reports resources using the Maven Ant Tasks
but you can also do it manually.
The latest version of the site resources is indeed 3.1.1 - the version is not
linked to the version of core or web.
Report stying not being generated
-
Key: JBEHAVE-501
URL: http://jira.codehaus.org/browse/JBEHAVE-501
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.2
Environment: Ant, Eclipse, JDK6
Reporter: Derek Clarkson
I am using this report builder definition in a annotation setup as per the
JBehave website documentation:
public static class MyReportBuilder extends StoryReporterBuilder {
public MyReportBuilder() {
super();
this.withCodeLocation(CodeLocations.codeLocationFromPath(build/publish/x));
this.withRelativeDirectory(story-reports);
this.withDefaultFormats();
this.withFormats(CONSOLE, HTML);
}
}
The reports are being generated in the view directory, however there are no
images, css or javascript being generated even though the html refers to
them. I've scoured the web site documentation which suggests that they should
be and tells you how to turn them off, but not what to do if they are not
there.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-506) Allow system properties to be specified for AnnotatedEmbedderRunner
Allow system properties to be specified for AnnotatedEmbedderRunner --- Key: JBEHAVE-506 URL: http://jira.codehaus.org/browse/JBEHAVE-506 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 The AnnotatedEmbedderRunner is missing the specification of system properties via the @UsingEmbedder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-504) Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties to embedder
[
http://jira.codehaus.org/browse/JBEHAVE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-504:
-
Description:
I'm trying to run JBehave from Ant using the following ant code:
{code:xml}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the log
showing the startup:
{code}
run-bdd-tests:
[runStoriesWithAnnotatedEmbedderRunner] Running stories with annotated embedder
org.jbehave.core.junit.AnnotatedEmbedderRunner
[runStoriesWithAnnotatedEmbedderRunner] Found class names :
[au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder]
[runStoriesWithAnnotatedEmbedderRunner] 2011-05-03 16:12:21,042 DEBUG
[runStoriesWithAnnotatedEmbedderRunner] Processing system properties {}
{code}
As you can see it's reporting no properties passed. Digging into the Ant task
code supports that the properties are not getting through, but from what I can
see in the source there is no obvious reason. Possibly the code that loads the
properties has a bug and is throwing an exception because it's try-catch
silently swallows any errors.
was:
I'm trying to run JBehave from Ant using the following ant code:
{code:ant}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the log
showing the startup:
{code}
run-bdd-tests:
[runStoriesWithAnnotatedEmbedderRunner] Running stories with annotated embedder
org.jbehave.core.junit.AnnotatedEmbedderRunner
[runStoriesWithAnnotatedEmbedderRunner] Found class names :
[au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder]
[runStoriesWithAnnotatedEmbedderRunner] 2011-05-03 16:12:21,042 DEBUG
[runStoriesWithAnnotatedEmbedderRunner] Processing system properties {}
{code}
As you can see it's reporting no properties passed. Digging into the Ant task
code supports that the properties are not getting through, but from what I can
see in the source there is no obvious reason. Possibly the code that loads the
properties has a bug and is throwing an exception because it's try-catch
silently swallows any errors.
Affects Version/s: (was: web-3.2)
3.3.2
Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties
to embedder
Key: JBEHAVE-504
URL: http://jira.codehaus.org/browse/JBEHAVE-504
Project: JBehave
Issue Type: Bug
Components: Ant Tasks
Affects Versions: 3.3.2
Environment: Ant
Reporter: Derek Clarkson
I'm trying to run JBehave from Ant using the following ant code:
{code:xml}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the
log showing the startup:
{code}
[jbehave-dev] [jira] Commented: (JBEHAVE-504) Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties to embedder
[
http://jira.codehaus.org/browse/JBEHAVE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265561#action_265561
]
Mauro Talevi commented on JBEHAVE-504:
--
Derek, system properties (or other configurable properties) are all ignored
when running with AnnotatedEmbedderRunner, which by design gets the Embedder
configuration from the annotation @UsingEmbedder.
The system properties were missing in the @UsingEmbedder (now fixed in
JBEHAVE-506).
If you want to specify your configuration via Ant task, you can use a
ConfigurableEmbedder instance, e.g. JUnitStories.
Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties
to embedder
Key: JBEHAVE-504
URL: http://jira.codehaus.org/browse/JBEHAVE-504
Project: JBehave
Issue Type: Bug
Components: Ant Tasks
Affects Versions: 3.3.2
Environment: Ant
Reporter: Derek Clarkson
I'm trying to run JBehave from Ant using the following ant code:
{code:xml}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the
log showing the startup:
{code}
run-bdd-tests:
[runStoriesWithAnnotatedEmbedderRunner] Running stories with annotated
embedder org.jbehave.core.junit.AnnotatedEmbedderRunner
[runStoriesWithAnnotatedEmbedderRunner] Found class names :
[au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder]
[runStoriesWithAnnotatedEmbedderRunner] 2011-05-03 16:12:21,042 DEBUG
[runStoriesWithAnnotatedEmbedderRunner] Processing system properties {}
{code}
As you can see it's reporting no properties passed. Digging into the Ant task
code supports that the properties are not getting through, but from what I
can see in the source there is no obvious reason. Possibly the code that
loads the properties has a bug and is throwing an exception because it's
try-catch silently swallows any errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-506) Allow system properties to be specified for AnnotatedEmbedderRunner
[ http://jira.codehaus.org/browse/JBEHAVE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-506. -- Resolution: Fixed Allow system properties to be specified for AnnotatedEmbedderRunner --- Key: JBEHAVE-506 URL: http://jira.codehaus.org/browse/JBEHAVE-506 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 The AnnotatedEmbedderRunner is missing the specification of system properties via the @UsingEmbedder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-505) Ant tasks running with incorrect classpath
[ http://jira.codehaus.org/browse/JBEHAVE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-505: - Affects Version/s: (was: web-3.2) 3.3.2 Ant tasks running with incorrect classpath -- Key: JBEHAVE-505 URL: http://jira.codehaus.org/browse/JBEHAVE-505 Project: JBehave Issue Type: Bug Components: Ant Tasks Affects Versions: 3.3.2 Reporter: Derek Clarkson I've been trying to make this work for hours now. It appears that the Ant tasks run the Embedders with the classpath used to run Ant and that there is no way to override this. This means I cannot run JBehave against the classpaths used to build and test the application. How do we specify a classpath for JBEhave's Ant tasks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-505) Ant tasks running with incorrect classpath
[ http://jira.codehaus.org/browse/JBEHAVE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265562#action_265562 ] Mauro Talevi commented on JBEHAVE-505: -- Classloading in Ant is less than transparent, so ATM it uses the classloader used to load the task itself. Feel free to provide a patch that specifies the classloader in the Ant way. Ant tasks running with incorrect classpath -- Key: JBEHAVE-505 URL: http://jira.codehaus.org/browse/JBEHAVE-505 Project: JBehave Issue Type: Bug Components: Ant Tasks Affects Versions: 3.3.2 Reporter: Derek Clarkson I've been trying to make this work for hours now. It appears that the Ant tasks run the Embedders with the classpath used to run Ant and that there is no way to override this. This means I cannot run JBehave against the classpaths used to build and test the application. How do we specify a classpath for JBEhave's Ant tasks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-503) Add Ant script example in trader-maps to show how to generate story maps
[ http://jira.codehaus.org/browse/JBEHAVE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-503: - Component/s: (was: Core) Documentation Fix Version/s: 3.4 Assignee: Mauro Talevi Issue Type: Task (was: Bug) Summary: Add Ant script example in trader-maps to show how to generate story maps (was: maps.html not being generated) Add Ant script example in trader-maps to show how to generate story maps Key: JBEHAVE-503 URL: http://jira.codehaus.org/browse/JBEHAVE-503 Project: JBehave Issue Type: Task Components: Documentation Affects Versions: 3.3.2 Reporter: Derek Clarkson Assignee: Mauro Talevi Fix For: 3.4 The generated reports include a link to a maps.html. But the file is not generated. How do I turn it on or remove the link? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-503) Add Ant script example in trader-maps to show how to generate story maps
[ http://jira.codehaus.org/browse/JBEHAVE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-503. -- Resolution: Fixed See examples/trader-maps/build.xml for an example of how to configure story map generation Add Ant script example in trader-maps to show how to generate story maps Key: JBEHAVE-503 URL: http://jira.codehaus.org/browse/JBEHAVE-503 Project: JBehave Issue Type: Task Components: Documentation Affects Versions: 3.3.2 Reporter: Derek Clarkson Assignee: Mauro Talevi Fix For: 3.4 The generated reports include a link to a maps.html. But the file is not generated. How do I turn it on or remove the link? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-497) Upgrade PicoContainer to 2.13.4
[ http://jira.codehaus.org/browse/JBEHAVE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-497. -- Resolution: Fixed Upgrade PicoContainer to 2.13.4 --- Key: JBEHAVE-497 URL: http://jira.codehaus.org/browse/JBEHAVE-497 Project: JBehave Issue Type: Improvement Components: Pico Support Reporter: Paul Hammant Assignee: Paul Hammant Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[ http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-492 started by Mauro Talevi. CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic -- Key: JBEHAVE-492 URL: http://jira.codehaus.org/browse/JBEHAVE-492 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 3.x Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: 3.4 In multi-threaded mode, the steps instances need to be instantiated per thread. A way to do this is to pass the InjectableStepsFactory to the StoryRunner run context and let the context instantiate the candidate steps per thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-497) Upgrade PicoContainer to 2.13.4
[ http://jira.codehaus.org/browse/JBEHAVE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-497: - Issue Type: Task (was: Improvement) Upgrade PicoContainer to 2.13.4 --- Key: JBEHAVE-497 URL: http://jira.codehaus.org/browse/JBEHAVE-497 Project: JBehave Issue Type: Task Components: Pico Support Reporter: Paul Hammant Assignee: Paul Hammant Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-502) Add installation instructions to website documentation
[ http://jira.codehaus.org/browse/JBEHAVE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-502: - Component/s: Documentation Add installation instructions to website documentation -- Key: JBEHAVE-502 URL: http://jira.codehaus.org/browse/JBEHAVE-502 Project: JBehave Issue Type: Task Components: Core, Documentation Reporter: Derek Clarkson Priority: Minor Fix For: 3.4 I've been scouring the site for a couple of days trying to figure out what I needed to install and where. I'm not using maven. The website doesn't give any idea of how to setup JBehave when not in a maven environment. So I'm having to do it by reverse engineering the maven pom. The first problem was to trying and figure out what to download. The linked download file is only of use in a maven world. So I had to start downloaded by surfing the online repos. So I'd suggest that the raw jars and zips should also be linked for download from the main site. The second issue was what to unzip, etc and suggested directories. Again the documentation takes a it will just work approach, which it doesn't. So instructions are needed here to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-502) Add installation instructions to website documentation
[ http://jira.codehaus.org/browse/JBEHAVE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-502: - Priority: Minor (was: Major) Issue Type: Task (was: Improvement) Add installation instructions to website documentation -- Key: JBEHAVE-502 URL: http://jira.codehaus.org/browse/JBEHAVE-502 Project: JBehave Issue Type: Task Components: Core, Documentation Reporter: Derek Clarkson Priority: Minor Fix For: 3.4 I've been scouring the site for a couple of days trying to figure out what I needed to install and where. I'm not using maven. The website doesn't give any idea of how to setup JBehave when not in a maven environment. So I'm having to do it by reverse engineering the maven pom. The first problem was to trying and figure out what to download. The linked download file is only of use in a maven world. So I had to start downloaded by surfing the online repos. So I'd suggest that the raw jars and zips should also be linked for download from the main site. The second issue was what to unzip, etc and suggested directories. Again the documentation takes a it will just work approach, which it doesn't. So instructions are needed here to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-507) unpack-view-resources goal requires resources to be in compile scope
[ http://jira.codehaus.org/browse/JBEHAVE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-507. -- Resolution: Fixed Changed dependency resolution of Maven goal unpack-view-resources to include test scope. No additional configuration is required when using goal. Updated the examples view resources to be at test scope and all the examples modules (running either at compile or test scope) can access the view resources. unpack-view-resources goal requires resources to be in compile scope Key: JBEHAVE-507 URL: http://jira.codehaus.org/browse/JBEHAVE-507 Project: JBehave Issue Type: Improvement Components: Maven Plugin Reporter: Caoilte O'Connor Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 Because I run JBehave in the test scope of the same project that it is testing I cannot use the compile scope for JBehave dependencies. However, the maven unpack-view-resources goal requires the resources to be in compile scope. This means that they get included in my final WAR. When I switch them to test scope the unpack-view-resources goal doesn't find them. I suppose the best fix would be to allow the unpack-view-resources goal to have its scope configured in the same way as the run-stories goals. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-501) Report stying not being generated
[
http://jira.codehaus.org/browse/JBEHAVE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-501.
--
Resolution: Not A Bug
Fix Version/s: 3.4
Report stying not being generated
-
Key: JBEHAVE-501
URL: http://jira.codehaus.org/browse/JBEHAVE-501
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.3.2
Environment: Ant, Eclipse, JDK6
Reporter: Derek Clarkson
Fix For: 3.4
I am using this report builder definition in a annotation setup as per the
JBehave website documentation:
public static class MyReportBuilder extends StoryReporterBuilder {
public MyReportBuilder() {
super();
this.withCodeLocation(CodeLocations.codeLocationFromPath(build/publish/x));
this.withRelativeDirectory(story-reports);
this.withDefaultFormats();
this.withFormats(CONSOLE, HTML);
}
}
The reports are being generated in the view directory, however there are no
images, css or javascript being generated even though the html refers to
them. I've scoured the web site documentation which suggests that they should
be and tells you how to turn them off, but not what to do if they are not
there.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-504) Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties to embedder
[
http://jira.codehaus.org/browse/JBEHAVE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-504.
--
Resolution: Won't Fix
Fix Version/s: 3.4
Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties
to embedder
Key: JBEHAVE-504
URL: http://jira.codehaus.org/browse/JBEHAVE-504
Project: JBehave
Issue Type: Bug
Components: Ant Tasks
Affects Versions: 3.3.2
Environment: Ant
Reporter: Derek Clarkson
Fix For: 3.4
I'm trying to run JBehave from Ant using the following ant code:
{code:xml}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the
log showing the startup:
{code}
run-bdd-tests:
[runStoriesWithAnnotatedEmbedderRunner] Running stories with annotated
embedder org.jbehave.core.junit.AnnotatedEmbedderRunner
[runStoriesWithAnnotatedEmbedderRunner] Found class names :
[au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder]
[runStoriesWithAnnotatedEmbedderRunner] 2011-05-03 16:12:21,042 DEBUG
[runStoriesWithAnnotatedEmbedderRunner] Processing system properties {}
{code}
As you can see it's reporting no properties passed. Digging into the Ant task
code supports that the properties are not getting through, but from what I
can see in the source there is no obvious reason. Possibly the code that
loads the properties has a bug and is throwing an exception because it's
try-catch silently swallows any errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-504) Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties to embedder
[
http://jira.codehaus.org/browse/JBEHAVE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265713#action_265713
]
Mauro Talevi commented on JBEHAVE-504:
--
You can also specify them programmatically via Java system properties in your
custom Embedder instance (configured via @UsingEmbedder). I've updated
TraderAnnotatedEmbedder example to show this in action (works with latest
snapshot).
Note though that if systemProperties are also specified in the @UsingEmbedder
they will override what you specify in your embedder, just like Ant/Maven
configuration override what is configured programmatically.
Ant task RunStoriesWithAnnotatedEmbedderRunner not passing system properties
to embedder
Key: JBEHAVE-504
URL: http://jira.codehaus.org/browse/JBEHAVE-504
Project: JBehave
Issue Type: Bug
Components: Ant Tasks
Affects Versions: 3.3.2
Environment: Ant
Reporter: Derek Clarkson
Fix For: 3.4
I'm trying to run JBehave from Ant using the following ant code:
{code:xml}
taskdef name=runStoriesWithAnnotatedEmbedderRunner
classname=org.jbehave.ant.RunStoriesWithAnnotatedEmbedderRunner
classpathref=integration.tests.classpath /
runStoriesWithAnnotatedEmbedderRunner includes=**/*StoryEmbedder.java
sourceDirectory=src/integration
systemProperties=java.awt.headless=true,web.project.dir=${build.integration.web.dir}
ignoreFailureInStories=true
ignoreFailureInView=false
generateViewAfterStories=true /
{code}
At the momment I'm getting a class not found which the story embedder I've
written starts up (doesn't happen from a junit run inside eclipse!).
I think that it's running from the default directory because it appears that
the systemProperties are not making it through to the embedder. Here's the
log showing the startup:
{code}
run-bdd-tests:
[runStoriesWithAnnotatedEmbedderRunner] Running stories with annotated
embedder org.jbehave.core.junit.AnnotatedEmbedderRunner
[runStoriesWithAnnotatedEmbedderRunner] Found class names :
[au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder]
[runStoriesWithAnnotatedEmbedderRunner] 2011-05-03 16:12:21,042 DEBUG
[runStoriesWithAnnotatedEmbedderRunner] Processing system properties {}
{code}
As you can see it's reporting no properties passed. Digging into the Ant task
code supports that the properties are not getting through, but from what I
can see in the source there is no obvious reason. Possibly the code that
loads the properties has a bug and is throwing an exception because it's
try-catch silently swallows any errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=266007#action_266007 ] Mauro Talevi commented on JBEHAVE-491: -- Moved to jbehave-spring-namespace branch until ready for release. Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.x I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-491) Add JBehave Spring Namespace support for easier configuration
[ http://jira.codehaus.org/browse/JBEHAVE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-491: - Affects Version/s: (was: 3.x) Fix Version/s: (was: 3.4) 3.x Add JBehave Spring Namespace support for easier configuration - Key: JBEHAVE-491 URL: http://jira.codehaus.org/browse/JBEHAVE-491 Project: JBehave Issue Type: New Feature Components: Spring Support Reporter: Alex Soto Bueno Assignee: Mauro Talevi Fix For: 3.x I have implemented an initial version, it is a clone of master branch of jbehave project. My implementation is on g...@github.com:maggandalf/jbehave-core.git Configuring Embedder for working with Spring shall be: jbehave:embedder id=embedder jbehave:classpathLoadertarget/classes/jbehave:classpathLoader jbehave:outputTXT/jbehave:output jbehave:outputHTML/jbehave:output jbehave:outputCONSOLE/jbehave:output /jbehave:embedder -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-511) Embedder should report in the monitor annotated embedder runner being used to run the stories
Embedder should report in the monitor annotated embedder runner being used to run the stories - Key: JBEHAVE-511 URL: http://jira.codehaus.org/browse/JBEHAVE-511 Project: JBehave Issue Type: Improvement Components: Ant Tasks, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-511) Embedder should report in the monitor annotated embedder runner being used to run the stories
[ http://jira.codehaus.org/browse/JBEHAVE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-511. -- Resolution: Fixed Embedder should report in the monitor annotated embedder runner being used to run the stories - Key: JBEHAVE-511 URL: http://jira.codehaus.org/browse/JBEHAVE-511 Project: JBehave Issue Type: Improvement Components: Ant Tasks, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-508) Curtailed stack traces for known failures.
[
http://jira.codehaus.org/browse/JBEHAVE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-508:
-
Summary: Curtailed stack traces for known failures. (was: Curtained
stack traces for known failures.)
Curtailed stack traces for known failures.
Key: JBEHAVE-508
URL: http://jira.codehaus.org/browse/JBEHAVE-508
Project: JBehave
Issue Type: Improvement
Components: Core
Reporter: Paul Hammant
Assignee: Paul Hammant
Priority: Minor
Fix For: 3.4
public void myStep {
throw new KnownFailure(CORBA down);
}
If we threw the above from the middle of a step, JBehave could list the step
as failing without stack trace in the outputs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-489) AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin causing build failures after an otherwise successful JBehav
[ http://jira.codehaus.org/browse/JBEHAVE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-489: - Fix Version/s: 3.4 AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin causing build failures after an otherwise successful JBehave job - Key: JBEHAVE-489 URL: http://jira.codehaus.org/browse/JBEHAVE-489 Project: JBehave Issue Type: Bug Components: Hudson Support Reporter: Paul Hammant Fix For: 3.4 AfterStories.xml can be zero bytes on occasion. BeforeStories.xml can have invalid XML on occasion. I'll assume its zero length because there were no @AfterStories steps that were run for the job in question ( I guess there were @BeforeStories steps that were run) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-446) JBehave Reports import to Hudson xUnit Error: Conversion error Error to convert - A file not found
[ http://jira.codehaus.org/browse/JBEHAVE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-446: - Fix Version/s: 3.4 JBehave Reports import to Hudson xUnit Error: Conversion error Error to convert - A file not found -- Key: JBEHAVE-446 URL: http://jira.codehaus.org/browse/JBEHAVE-446 Project: JBehave Issue Type: Bug Components: Hudson Support Affects Versions: 3.2 Reporter: Sven Schäfer Fix For: 3.4 Attachments: jbehave-hudson-test-project.zip Hi, i know about some similar tasks JBEHAVE-394, but i think this does not resolve my problem. In my test project(see Attachment) i added a story(ist_produkt_in_bestand.story) with GivenStories. The report xml for that story is currupted because two end-tags are missing. /scenario/story That failure takes place with version 3.1.2, 3.2-beta 1..5, 3.2 and 3.3-beta-1. I think it is realy possible that i doing something wrong with the configuration src/test/java...jbehave.config.TraderEmbedderRunner. If it is, tell me pleace how i change it. My Hudson config: jbehave-hudson-plugin 3.2-beta-5 xUnit 1.13 Thanks for your help. Best regards Sven Schäfer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-498) withRelativeDirectory appears to be broken
[
http://jira.codehaus.org/browse/JBEHAVE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-498:
-
Affects Version/s: (was: web-3.3)
Fix Version/s: 3.4
withRelativeDirectory appears to be broken
--
Key: JBEHAVE-498
URL: http://jira.codehaus.org/browse/JBEHAVE-498
Project: JBehave
Issue Type: Bug
Components: Core
Environment: Linux. Jdk6
Reporter: Derek Clarkson
Fix For: 3.4
I'm working in a non maven environment. I attempted to set the output
directory for reports as follows
public static class MyReportBuilder extends StoryReporterBuilder {
public MyReportBuilder() {
super();
this.withRelativeDirectory(../build/publish/story-reports);
this.withFormats(CONSOLE, HTML, XML);
}
}
Upon running the JUnits I get the following:
org.jbehave.core.reporters.FilePrintStreamFactory$PrintStreamCreationFailed:
Failed to create print stream for file
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
at
org.jbehave.core.reporters.FilePrintStreamFactory.createPrintStream(FilePrintStreamFactory.java:39)
at
org.jbehave.core.reporters.Format$4.createStoryReporter(Format.java:43)
at
org.jbehave.core.reporters.StoryReporterBuilder.reporterFor(StoryReporterBuilder.java:310)
at
org.jbehave.core.reporters.StoryReporterBuilder.build(StoryReporterBuilder.java:285)
at
org.jbehave.core.configuration.Configuration.storyReporter(Configuration.java:200)
at
org.jbehave.core.embedder.StoryRunner.runBeforeOrAfterStories(StoryRunner.java:58)
at
org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:209)
at
au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder.run(AnnotatedStoryEmbedder.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.FileNotFoundException:
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
(No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at
org.jbehave.core.reporters.FilePrintStreamFactory$FilePrintStream.init(FilePrintStreamFactory.java:137)
at
org.jbehave.core.reporters.FilePrintStreamFactory.createPrintStream(FilePrintStreamFactory.java:37)
... 31 more
Commenting out the withRelativeDirectory() method and everything works just
fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jbehave-dev] [jira] Created: (JBEHAVE-512) GivenStories path list should be more tollerant with spaces
GivenStories path list should be more tollerant with spaces --- Key: JBEHAVE-512 URL: http://jira.codehaus.org/browse/JBEHAVE-512 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 We should allow paths to be padded with spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-512) GivenStories path list should be more tollerant with spaces
[ http://jira.codehaus.org/browse/JBEHAVE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-512. -- Resolution: Fixed GivenStories path list should be more tollerant with spaces --- Key: JBEHAVE-512 URL: http://jira.codehaus.org/browse/JBEHAVE-512 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 We should allow paths to be padded with spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-489) AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin
[ http://jira.codehaus.org/browse/JBEHAVE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-489: - Component/s: Core Description: AfterStories.xml can be zero bytes on occasion. BeforeStories.xml can have invalid XML on occasion. was: AfterStories.xml can be zero bytes on occasion. BeforeStories.xml can have invalid XML on occasion. I'll assume its zero length because there were no @AfterStories steps that were run for the job in question ( I guess there were @BeforeStories steps that were run) Summary: AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin (was: AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin causing build failures after an otherwise successful JBehave job) AfterStories.xml and BeforeStories.xml being corrupt or zero length will break the Hudson plugin - Key: JBEHAVE-489 URL: http://jira.codehaus.org/browse/JBEHAVE-489 Project: JBehave Issue Type: Bug Components: Core, Hudson Support Reporter: Paul Hammant Fix For: 3.4 AfterStories.xml can be zero bytes on occasion. BeforeStories.xml can have invalid XML on occasion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-513) @Before/AfterStories executions that have failed should be highlighted in red in the reports.hml entries
@Before/AfterStories executions that have failed should be highlighted in red in the reports.hml entries Key: JBEHAVE-513 URL: http://jira.codehaus.org/browse/JBEHAVE-513 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 These are executions that are not bound to scenarios. The failed status in the reports.html should be triggered by either failed scenarios or failed steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[ http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-492. -- Resolution: Fixed CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic -- Key: JBEHAVE-492 URL: http://jira.codehaus.org/browse/JBEHAVE-492 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 3.x Reporter: Paul Hammant Assignee: Mauro Talevi Fix For: 3.4 In multi-threaded mode, the steps instances need to be instantiated per thread. A way to do this is to pass the InjectableStepsFactory to the StoryRunner run context and let the context instantiate the candidate steps per thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-472) Improve state management of StoryRunner
[ http://jira.codehaus.org/browse/JBEHAVE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-472. -- Resolution: Fixed Improve state management of StoryRunner --- Key: JBEHAVE-472 URL: http://jira.codehaus.org/browse/JBEHAVE-472 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 3.3 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 We need to improve the state management of the StoryRunner. Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd behaviours when there are failure in the @Before steps but not in the normal steps. Examples of such a behaviour are the trader failing_before_after.story and failing_before_stories.story. A better and more intuitive state management should be in place, keeping state in the run context. The state should be reset by default before each scenario (to ensure backward compat) but will be shared between the @Before/@After steps and the normal steps. We should also have the option to not reset it before each scenario to allow for failures in the @BeforeStory/Stories steps to propagate to the scenario steps in the same run context. Once a failing state in a given run context, the steps that follow will not be performed, as customary with normal steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-514) jbehave-maven-plugin ignoring execution
[
http://jira.codehaus.org/browse/JBEHAVE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=266635#action_266635
]
Mauro Talevi commented on JBEHAVE-514:
--
Have you tried executing:
{code}
mvn clean install
{code}
The Maven goal is bound by default to the integration-test phase, so you don't
need to specify the goal.
jbehave-maven-plugin ignoring execution
---
Key: JBEHAVE-514
URL: http://jira.codehaus.org/browse/JBEHAVE-514
Project: JBehave
Issue Type: Bug
Components: Maven Plugin
Affects Versions: web-3.3.2
Environment: Ubuntu 10.4
Java 1.6
STS (Eclipse)
Maven 3.0-SNAPSHOT/0.10.0.201202009-0800) (via STS) or
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux version: 2.6.32-31-generic arch: amd64 Family: unix
JBehave 3.3.2
jbehave-maven-plugin 3.3.2
Reporter: Gavin Tranter
Priority: Critical
Fix For: 3.x
when trying to execute a package on a maven project with jbehave and
jbehave-maven-plugin configured Maven fails to execute the jbehave goal.
This is regardless of weather I execute it with in Eclipse or on the
commandline.
However if I issue the following command on the command line the
jbehave-maven-plugin is executed and runs the acceptance tests:
mvn clean package
org.jbehave:jbehave-maven-plugin:3.3.2:run-stories-as-embeddables
The command I use in Eclipse is:
jbehave:run-stories-as-embeddables
I have configured the jbehave plugin:
{noformat}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
/configuration
/plugin
plugin
groupIdorg.jbehave/groupId
artifactIdjbehave-maven-plugin/artifactId
version3.3.2/version
configuration
scopetest/scope
includes
include**/*.java/include
/includes
metaFilters
metaFilter+author */metaFilter
metaFilter-skip/metaFilter
/metaFilters
systemProperties
property
namejava.awt.headless/name
valuetrue/value
/property
/systemProperties
ignoreFailureInStoriestrue/ignoreFailureInStories
ignoreFailureInViewfalse/ignoreFailureInView
/configuration
executions
execution
idrun-stories-as-embeddables/id
phasetest/phase
goals
goalrun-stories-as-embeddables/goal
/goals
/execution
/executions
/plugin
/plugins
{noformat}
Thanks
Gavin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-514) jbehave-maven-plugin ignoring execution
[
http://jira.codehaus.org/browse/JBEHAVE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=266638#action_266638
]
Mauro Talevi commented on JBEHAVE-514:
--
To run in Eclipse, install http://m2eclipse.sonatype.org/ and execute 'Run As'
... 'Maven install'
jbehave-maven-plugin ignoring execution
---
Key: JBEHAVE-514
URL: http://jira.codehaus.org/browse/JBEHAVE-514
Project: JBehave
Issue Type: Bug
Components: Maven Plugin
Affects Versions: web-3.3.2
Environment: Ubuntu 10.4
Java 1.6
STS (Eclipse)
Maven 3.0-SNAPSHOT/0.10.0.201202009-0800) (via STS) or
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux version: 2.6.32-31-generic arch: amd64 Family: unix
JBehave 3.3.2
jbehave-maven-plugin 3.3.2
Reporter: Gavin Tranter
Priority: Critical
Fix For: 3.x
when trying to execute a package on a maven project with jbehave and
jbehave-maven-plugin configured Maven fails to execute the jbehave goal.
This is regardless of weather I execute it with in Eclipse or on the
commandline.
However if I issue the following command on the command line the
jbehave-maven-plugin is executed and runs the acceptance tests:
mvn clean package
org.jbehave:jbehave-maven-plugin:3.3.2:run-stories-as-embeddables
The command I use in Eclipse is:
jbehave:run-stories-as-embeddables
I have configured the jbehave plugin:
{noformat}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
/configuration
/plugin
plugin
groupIdorg.jbehave/groupId
artifactIdjbehave-maven-plugin/artifactId
version3.3.2/version
configuration
scopetest/scope
includes
include**/*.java/include
/includes
metaFilters
metaFilter+author */metaFilter
metaFilter-skip/metaFilter
/metaFilters
systemProperties
property
namejava.awt.headless/name
valuetrue/value
/property
/systemProperties
ignoreFailureInStoriestrue/ignoreFailureInStories
ignoreFailureInViewfalse/ignoreFailureInView
/configuration
executions
execution
idrun-stories-as-embeddables/id
phasetest/phase
goals
goalrun-stories-as-embeddables/goal
/goals
/execution
/executions
/plugin
/plugins
{noformat}
Thanks
Gavin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-514) jbehave-maven-plugin ignoring execution
[
http://jira.codehaus.org/browse/JBEHAVE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=266655#action_266655
]
Mauro Talevi commented on JBEHAVE-514:
--
Difficult to help you without seeing your full project. You could either
upload the simplified project (simplest possible the reproduces the problem) or
you could generate a working project using an archetype - a new feature of 3.4
(see http://jbehave.org/reference/preview/archetypes.html).
jbehave-maven-plugin ignoring execution
---
Key: JBEHAVE-514
URL: http://jira.codehaus.org/browse/JBEHAVE-514
Project: JBehave
Issue Type: Bug
Components: Maven Plugin
Affects Versions: web-3.3.2
Environment: Ubuntu 10.4
Java 1.6
STS (Eclipse)
Maven 3.0-SNAPSHOT/0.10.0.201202009-0800) (via STS) or
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux version: 2.6.32-31-generic arch: amd64 Family: unix
JBehave 3.3.2
jbehave-maven-plugin 3.3.2
Reporter: Gavin Tranter
Priority: Critical
Fix For: 3.x
when trying to execute a package on a maven project with jbehave and
jbehave-maven-plugin configured Maven fails to execute the jbehave goal.
This is regardless of weather I execute it with in Eclipse or on the
commandline.
However if I issue the following command on the command line the
jbehave-maven-plugin is executed and runs the acceptance tests:
mvn clean package
org.jbehave:jbehave-maven-plugin:3.3.2:run-stories-as-embeddables
The command I use in Eclipse is:
jbehave:run-stories-as-embeddables
I have configured the jbehave plugin:
{noformat}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
/configuration
/plugin
plugin
groupIdorg.jbehave/groupId
artifactIdjbehave-maven-plugin/artifactId
version3.3.2/version
configuration
scopetest/scope
includes
include**/*.java/include
/includes
metaFilters
metaFilter+author */metaFilter
metaFilter-skip/metaFilter
/metaFilters
systemProperties
property
namejava.awt.headless/name
valuetrue/value
/property
/systemProperties
ignoreFailureInStoriestrue/ignoreFailureInStories
ignoreFailureInViewfalse/ignoreFailureInView
/configuration
executions
execution
idrun-stories-as-embeddables/id
phasetest/phase
goals
goalrun-stories-as-embeddables/goal
/goals
/execution
/executions
/plugin
/plugins
{noformat}
Thanks
Gavin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-515) Create trader-ant example
Create trader-ant example - Key: JBEHAVE-515 URL: http://jira.codehaus.org/browse/JBEHAVE-515 Project: JBehave Issue Type: Task Components: Ant Tasks Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 Move the examples of using Ant from trader to a new trader-ant example module, in order to make it easier for Ant users to identify it and get started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-498) withRelativeDirectory appears to be broken
[
http://jira.codehaus.org/browse/JBEHAVE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-498:
-
Fix Version/s: (was: 3.4)
3.x
withRelativeDirectory appears to be broken
--
Key: JBEHAVE-498
URL: http://jira.codehaus.org/browse/JBEHAVE-498
Project: JBehave
Issue Type: Bug
Components: Core
Environment: Linux. Jdk6
Reporter: Derek Clarkson
Fix For: 3.x
I'm working in a non maven environment. I attempted to set the output
directory for reports as follows
public static class MyReportBuilder extends StoryReporterBuilder {
public MyReportBuilder() {
super();
this.withRelativeDirectory(../build/publish/story-reports);
this.withFormats(CONSOLE, HTML, XML);
}
}
Upon running the JUnits I get the following:
org.jbehave.core.reporters.FilePrintStreamFactory$PrintStreamCreationFailed:
Failed to create print stream for file
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
at
org.jbehave.core.reporters.FilePrintStreamFactory.createPrintStream(FilePrintStreamFactory.java:39)
at
org.jbehave.core.reporters.Format$4.createStoryReporter(Format.java:43)
at
org.jbehave.core.reporters.StoryReporterBuilder.reporterFor(StoryReporterBuilder.java:310)
at
org.jbehave.core.reporters.StoryReporterBuilder.build(StoryReporterBuilder.java:285)
at
org.jbehave.core.configuration.Configuration.storyReporter(Configuration.java:200)
at
org.jbehave.core.embedder.StoryRunner.runBeforeOrAfterStories(StoryRunner.java:58)
at
org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:209)
at
au.com.sensis.wireless.smsmanager.integration.bdd.stories.AnnotatedStoryEmbedder.run(AnnotatedStoryEmbedder.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.FileNotFoundException:
/home/derek/workspace/smsManagerGit/target/../build/publish/story-reports/BeforeStories.html
(No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at
org.jbehave.core.reporters.FilePrintStreamFactory$FilePrintStream.init(FilePrintStreamFactory.java:137)
at
org.jbehave.core.reporters.FilePrintStreamFactory.createPrintStream(FilePrintStreamFactory.java:37)
... 31 more
Commenting out the withRelativeDirectory() method and everything works just
fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
[jbehave-dev] [jira] Updated: (JBEHAVE-517) Change SeleniumPage to implement Selenium (and delegate to methods)
[ http://jira.codehaus.org/browse/JBEHAVE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-517: - Fix Version/s: web-3.3.3 Issue Type: Improvement (was: New Feature) Change SeleniumPage to implement Selenium (and delegate to methods) --- Key: JBEHAVE-517 URL: http://jira.codehaus.org/browse/JBEHAVE-517 Project: JBehave Issue Type: Improvement Components: Web Selenium Affects Versions: web-3.3.2 Reporter: Paul Hammant Assignee: Paul Hammant Fix For: web-3.3.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-518) Use of PageFactory (WebDriver idiom) can access LazyWebDriver instance, but required extended interfaces like JavascriptExecutor
[ http://jira.codehaus.org/browse/JBEHAVE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-518: - Fix Version/s: web-3.3.3 Use of PageFactory (WebDriver idiom) can access LazyWebDriver instance, but required extended interfaces like JavascriptExecutor Key: JBEHAVE-518 URL: http://jira.codehaus.org/browse/JBEHAVE-518 Project: JBehave Issue Type: Bug Components: Web Selenium Affects Versions: web-3.3.2 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: web-3.3.3 makeNonLazy() should be protected, so it can be called by subclasses. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-519) Table parameters should be formatted as styleable HTML tables
[ http://jira.codehaus.org/browse/JBEHAVE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-519. -- Resolution: Fixed Table parameters should be formatted as styleable HTML tables --- Key: JBEHAVE-519 URL: http://jira.codehaus.org/browse/JBEHAVE-519 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4 Allow table parameters to be formatted as HTML tables and styleable as other tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-467) Increase unit test coverage
[ http://jira.codehaus.org/browse/JBEHAVE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-467. -- Resolution: Fixed Increase unit test coverage --- Key: JBEHAVE-467 URL: http://jira.codehaus.org/browse/JBEHAVE-467 Project: JBehave Issue Type: Task Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4 Unit test coverage has slipped from the 100%-ish level it had reached over the past couple of releases. It should be brought up again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-520) NPE in StoryRunner:76 [currentStrategy.get().handleFailure(storyFailure.get());] - causing org.jbehave.core.embedder.Embedder$RunningStoriesFailed: Failur
[ http://jira.codehaus.org/browse/JBEHAVE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268442#action_268442 ] Mauro Talevi commented on JBEHAVE-520: -- Only occurs if you use multiple threads. Need to investigate why, but for nos stick to 1 thread. NPE in StoryRunner:76 [currentStrategy.get().handleFailure(storyFailure.get());] - causing org.jbehave.core.embedder.Embedder$RunningStoriesFailed: Failures in running before or after stories steps - Key: JBEHAVE-520 URL: http://jira.codehaus.org/browse/JBEHAVE-520 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 3.4 Environment: Windowx XP, mvn 3.0.3 and 2.2.1, jbehave 3.4 Reporter: Maciej Madej Priority: Critical Fix For: 3.4 Attachments: jbehave-after-before-bug.zip I got following exception when building attached project (mvn clean install): --- Test set: pl.mmadej.jbehave.JBehaveStoriesTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.562 sec FAILURE! [run_with_no_replacement.story](pl.mmadej.jbehave.JBehaveStoriesTest) Time elapsed: 0.343 sec ERROR! org.jbehave.core.embedder.Embedder$RunningStoriesFailed: Failures in running before or after stories steps at org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:210) at pl.mmadej.jbehave.JBehaveStoriesTest.run(JBehaveStoriesTest.java:99) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Please investigate. This error happens with jbehave 3.4. When I'm using 3.3.2 everything looks ok. Internally there is NPE in StoryRunner:76 -- currentStrategy.get().handleFailure(storyFailure.get()); currentStrategy.get() returns null. Please investigate. Thanks in advance for your help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-521) Typo in jbehave-spring-archetype causes malformed pom.xml
Typo in jbehave-spring-archetype causes malformed pom.xml - Key: JBEHAVE-521 URL: http://jira.codehaus.org/browse/JBEHAVE-521 Project: JBehave Issue Type: Bug Components: Archetypes Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.4.1 /jbehave.sitee.version - /jbehave.site.version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-522) Add documentation page on tutorials
Add documentation page on tutorials --- Key: JBEHAVE-522 URL: http://jira.codehaus.org/browse/JBEHAVE-522 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
