[jbehave-dev] [jira] Commented: (JBEHAVE-368) Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven
[ http://jira.codehaus.org/browse/JBEHAVE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240257#action_240257 ] Mauro Talevi commented on JBEHAVE-368: -- Daniel, fix in 3.1-beta-2. Could you please try it out and let us know if it works on your build? Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven - Key: JBEHAVE-368 URL: http://jira.codehaus.org/browse/JBEHAVE-368 Project: JBehave Issue Type: Bug Components: Ant Tasks, Maven Plugin Affects Versions: 3.0.2 Environment: Maven 2.2.1 and JDK 1.6 Reporter: Daniel Godfrey Assignee: Mauro Talevi Fix For: 3.1 Attachments: jb.patch I'm getting the following stacktrace when using the ServiceLoader infrastructure in my JBehave steps while running under the maven plugin. I think this is caused by using different class loaders to find the stories and then to execute them. It starts working if I patch createClassLoader in AbstractEmbedderMojo to cache the created classloader and to reuse that every time. java.lang.ClassCastException at java.lang.Class.cast(Class.java:2990) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345) at java.util.ServiceLoader$1.next(ServiceLoader.java:421) at com.salerio.idm.service.AdaptorsModule.configure(AdaptorsModule.java:33) at com.google.inject.AbstractModule.configure(AbstractModule.java:59) at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223) at com.google.inject.spi.Elements.getElements(Elements.java:101) at com.google.inject.InjectorShell$Builder.build(InjectorShell.java:135) at com.google.inject.InjectorBuilder.build(InjectorBuilder.java:102) at com.google.inject.Guice.createInjector(Guice.java:92) at com.google.inject.Guice.createInjector(Guice.java:69) at functional.BaseFixture.initializeInjector(BaseFixture.java:272) at functional.BaseFixture.initialize(BaseFixture.java:104) at bdd.FixedIncomeSteps.init(FixedIncomeSteps.java:36) 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.jbehave.core.steps.StepCreator$BeforeOrAfter.run(StepCreator.java:348) at org.jbehave.core.steps.StepCreator$1.perform(StepCreator.java:74) at org.jbehave.core.embedder.StoryRunner$FineSoFar.run(StoryRunner.java:202) at org.jbehave.core.embedder.StoryRunner.runSteps(StoryRunner.java:187) at org.jbehave.core.embedder.StoryRunner.runStorySteps(StoryRunner.java:170) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:84) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:63) at org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:194) at bdd.MyStories.run(MyStories.java:52) at org.jbehave.core.embedder.Embedder.runStoriesWithAnnotatedEmbedderRunner(Embedder.java:137) at org.jbehave.mojo.RunStoriesWithAnnotatedEmbedderRunner.execute(RunStoriesWithAnnotatedEmbedderRunner.java:20) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jbehave-dev] [jira] Issue Comment Edited: (JBEHAVE-368) Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven
[ http://jira.codehaus.org/browse/JBEHAVE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240259#action_240259 ] Daniel Godfrey edited comment on JBEHAVE-368 at 10/20/10 4:19 AM: -- Yep, works fine thanks. was (Author: dgodfrey99): Yep, works fine. Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven - Key: JBEHAVE-368 URL: http://jira.codehaus.org/browse/JBEHAVE-368 Project: JBehave Issue Type: Bug Components: Ant Tasks, Maven Plugin Affects Versions: 3.0.2 Environment: Maven 2.2.1 and JDK 1.6 Reporter: Daniel Godfrey Assignee: Mauro Talevi Fix For: 3.1 Attachments: jb.patch I'm getting the following stacktrace when using the ServiceLoader infrastructure in my JBehave steps while running under the maven plugin. I think this is caused by using different class loaders to find the stories and then to execute them. It starts working if I patch createClassLoader in AbstractEmbedderMojo to cache the created classloader and to reuse that every time. java.lang.ClassCastException at java.lang.Class.cast(Class.java:2990) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345) at java.util.ServiceLoader$1.next(ServiceLoader.java:421) at com.salerio.idm.service.AdaptorsModule.configure(AdaptorsModule.java:33) at com.google.inject.AbstractModule.configure(AbstractModule.java:59) at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223) at com.google.inject.spi.Elements.getElements(Elements.java:101) at com.google.inject.InjectorShell$Builder.build(InjectorShell.java:135) at com.google.inject.InjectorBuilder.build(InjectorBuilder.java:102) at com.google.inject.Guice.createInjector(Guice.java:92) at com.google.inject.Guice.createInjector(Guice.java:69) at functional.BaseFixture.initializeInjector(BaseFixture.java:272) at functional.BaseFixture.initialize(BaseFixture.java:104) at bdd.FixedIncomeSteps.init(FixedIncomeSteps.java:36) 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.jbehave.core.steps.StepCreator$BeforeOrAfter.run(StepCreator.java:348) at org.jbehave.core.steps.StepCreator$1.perform(StepCreator.java:74) at org.jbehave.core.embedder.StoryRunner$FineSoFar.run(StoryRunner.java:202) at org.jbehave.core.embedder.StoryRunner.runSteps(StoryRunner.java:187) at org.jbehave.core.embedder.StoryRunner.runStorySteps(StoryRunner.java:170) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:84) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:63) at org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:194) at bdd.MyStories.run(MyStories.java:52) at org.jbehave.core.embedder.Embedder.runStoriesWithAnnotatedEmbedderRunner(Embedder.java:137) at org.jbehave.mojo.RunStoriesWithAnnotatedEmbedderRunner.execute(RunStoriesWithAnnotatedEmbedderRunner.java:20) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jbehave-dev] [jira] Commented: (JBEHAVE-368) Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven
[ http://jira.codehaus.org/browse/JBEHAVE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240259#action_240259 ] Daniel Godfrey commented on JBEHAVE-368: Yep, works fine. Ensure same instance of EmbedderClassLoader is used to find and run stories from Ant or Maven - Key: JBEHAVE-368 URL: http://jira.codehaus.org/browse/JBEHAVE-368 Project: JBehave Issue Type: Bug Components: Ant Tasks, Maven Plugin Affects Versions: 3.0.2 Environment: Maven 2.2.1 and JDK 1.6 Reporter: Daniel Godfrey Assignee: Mauro Talevi Fix For: 3.1 Attachments: jb.patch I'm getting the following stacktrace when using the ServiceLoader infrastructure in my JBehave steps while running under the maven plugin. I think this is caused by using different class loaders to find the stories and then to execute them. It starts working if I patch createClassLoader in AbstractEmbedderMojo to cache the created classloader and to reuse that every time. java.lang.ClassCastException at java.lang.Class.cast(Class.java:2990) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345) at java.util.ServiceLoader$1.next(ServiceLoader.java:421) at com.salerio.idm.service.AdaptorsModule.configure(AdaptorsModule.java:33) at com.google.inject.AbstractModule.configure(AbstractModule.java:59) at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223) at com.google.inject.spi.Elements.getElements(Elements.java:101) at com.google.inject.InjectorShell$Builder.build(InjectorShell.java:135) at com.google.inject.InjectorBuilder.build(InjectorBuilder.java:102) at com.google.inject.Guice.createInjector(Guice.java:92) at com.google.inject.Guice.createInjector(Guice.java:69) at functional.BaseFixture.initializeInjector(BaseFixture.java:272) at functional.BaseFixture.initialize(BaseFixture.java:104) at bdd.FixedIncomeSteps.init(FixedIncomeSteps.java:36) 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.jbehave.core.steps.StepCreator$BeforeOrAfter.run(StepCreator.java:348) at org.jbehave.core.steps.StepCreator$1.perform(StepCreator.java:74) at org.jbehave.core.embedder.StoryRunner$FineSoFar.run(StoryRunner.java:202) at org.jbehave.core.embedder.StoryRunner.runSteps(StoryRunner.java:187) at org.jbehave.core.embedder.StoryRunner.runStorySteps(StoryRunner.java:170) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:84) at org.jbehave.core.embedder.StoryRunner.run(StoryRunner.java:63) at org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:194) at bdd.MyStories.run(MyStories.java:52) at org.jbehave.core.embedder.Embedder.runStoriesWithAnnotatedEmbedderRunner(Embedder.java:137) at org.jbehave.mojo.RunStoriesWithAnnotatedEmbedderRunner.execute(RunStoriesWithAnnotatedEmbedderRunner.java:20) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[jbehave-dev] [jira] Updated: (JBEHAVE-364) Order-preserving ExamplesTable
[ http://jira.codehaus.org/browse/JBEHAVE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-364: - Fix Version/s: 3.1 Order-preserving ExamplesTable -- Key: JBEHAVE-364 URL: http://jira.codehaus.org/browse/JBEHAVE-364 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Currently the ExampleTable does not guarantee order of the columns since the row is returned as a Map. In some cases, the preserving the order of the textual table may be useful in the implementation of the step. -- 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-369) Allow processing of system processing before stories are run
Allow processing of system processing before stories are run Key: JBEHAVE-369 URL: http://jira.codehaus.org/browse/JBEHAVE-369 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Some systems used to implement steps may use system properties to control or override their behaviour. E.g. WebDriver system properties to override the default location of the browsers. While system properties may be set at command-line via -D parameters, it is useful to be able to set them via the Embedder and set them before the stories are run. The system properties should also be configurable via Ant or Maven. -- 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-370) IDE_CONSOLE no longer any different to IDE (w.r.t console output)
IDE_CONSOLE no longer any different to IDE (w.r.t console output) - Key: JBEHAVE-370 URL: http://jira.codehaus.org/browse/JBEHAVE-370 Project: JBehave Issue Type: Bug Affects Versions: 3.1 Reporter: Paul Hammant Fix For: 3.1 I've noticed recently a problem with IDE_CONSOLE. It (or more particularly the IdeOnlyConsoleOutput class) is being ignored. If you do a Maven run from the command line, for a project that uses a normal on JB3.1/JUnit tool chain you can see it. Put in a strategic throw, or loop/sys-out for the current threads stack trace, you don't have the prerequisite packages in the stack (I've checked), yet it still dump to console :-( Maybe there is a System.out somewhere that is ignore this configuration choice. -- 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-371) Leading and trailing spaces in example table cells are removed
Leading and trailing spaces in example table cells are removed
--
Key: JBEHAVE-371
URL: http://jira.codehaus.org/browse/JBEHAVE-371
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.0.3
Reporter: Frank Grimm
Priority: Minor
In JBehave Core 3.0.3 all leading and trailing spaces are removed from example
table cells.
For example, when accessed through the ExamplesTable API (the following table
{code}
| |A | B | C|
| |X | Y | Z|
{code}
becomes
{code}
||A|B|C|
||X|Y|Z|
{code}
Leading/trailing spaces were not removed for JBehave Core versions older than
3.0.3. So, it might be a regression cause when this
http://jira.codehaus.org/browse/JBEHAVE-353 was fixed.
At least for me it would be nice to be able to use example tables containing
cells with leading/trailing 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] Commented: (JBEHAVE-371) Leading and trailing spaces in example table cells are removed
[
http://jira.codehaus.org/browse/JBEHAVE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240320#action_240320
]
Mauro Talevi commented on JBEHAVE-371:
--
Frank, what's the use case for keeping the spaces?
Leading and trailing spaces in example table cells are removed
--
Key: JBEHAVE-371
URL: http://jira.codehaus.org/browse/JBEHAVE-371
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.0.3
Reporter: Frank Grimm
Priority: Minor
In JBehave Core 3.0.3 all leading and trailing spaces are removed from
example table cells.
For example, when accessed through the ExamplesTable API (the following table
{code}
| |A | B | C|
| |X | Y | Z|
{code}
becomes
{code}
||A|B|C|
||X|Y|Z|
{code}
Leading/trailing spaces were not removed for JBehave Core versions older than
3.0.3. So, it might be a regression cause when this
http://jira.codehaus.org/browse/JBEHAVE-353 was fixed.
At least for me it would be nice to be able to use example tables containing
cells with leading/trailing 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] Commented: (JBEHAVE-371) Leading and trailing spaces in example table cells are removed
[
http://jira.codehaus.org/browse/JBEHAVE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240335#action_240335
]
Mauro Talevi commented on JBEHAVE-371:
--
It's actually trivial to not trim the table cells, but the real point is that
most users would find that less useful or annoying to have to trim it
themselves. We need to find a way to support multiple parsing modes, whist
using the same parser (the ExamplesTable model class).
Some optional parsing meta info before the table data might do the trick,
identified as anything in [] before first header separator. E.g.:
{code}
[trim=false]
| |A | B | C|
| |X | Y | Z|
{code}
Then we could also add other directives, e.g. for the default sorting of the
data.
Leading and trailing spaces in example table cells are removed
--
Key: JBEHAVE-371
URL: http://jira.codehaus.org/browse/JBEHAVE-371
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.0.3
Reporter: Frank Grimm
Priority: Minor
In JBehave Core 3.0.3 all leading and trailing spaces are removed from
example table cells.
For example, when accessed through the ExamplesTable API (the following table
{code}
| |A | B | C|
| |X | Y | Z|
{code}
becomes
{code}
||A|B|C|
||X|Y|Z|
{code}
Leading/trailing spaces were not removed for JBehave Core versions older than
3.0.3. So, it might be a regression cause when this
http://jira.codehaus.org/browse/JBEHAVE-353 was fixed.
At least for me it would be nice to be able to use example tables containing
cells with leading/trailing 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-scm] jbehave-core branch, master, updated. jbehave-3.1-beta-2-2-g8fd386f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project jbehave-core. The branch, master has been updated via 8fd386f35b6d68777e338db651e3281d931bb2b8 (commit) from 8383d6b61c4d05c734b50211de031766cfe53378 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8fd386f35b6d68777e338db651e3281d931bb2b8 Author: Mauro Talevi mauro.tal...@aquilonia.org Date: Wed Oct 20 19:37:49 2010 +0200 JBEHAVE-369: Allow specification of system properties to be processed before running or mapping stories. --- Summary of changes: examples/trader/pom.xml| 14 +--- .../java/org/jbehave/ant/AbstractEmbedderTask.java | 33 .../org/jbehave/ant/EmbedderTaskBehaviour.java | 19 +++ .../java/org/jbehave/core/embedder/Embedder.java | 31 +-- .../org/jbehave/core/embedder/EmbedderMonitor.java |3 ++ .../core/embedder/PrintStreamEmbedderMonitor.java |9 + .../jbehave/core/embedder/EmbedderBehaviour.java | 33 +++- .../org/jbehave/mojo/AbstractEmbedderMojo.java | 19 +++ .../org/jbehave/mojo/EmbedderMojoBehaviour.java| 19 +++- 9 files changed, 170 insertions(+), 10 deletions(-) hooks/post-receive -- jbehave-core hr/ p To unsubscribe from this list please visit: /p p a href=http://xircles.codehaus.org/manage_email;http://xircles.codehaus.org/manage_email/a
[jbehave-dev] [jira] Resolved: (JBEHAVE-364) Ensure ExamplesTable preserves ordering of columns
[ http://jira.codehaus.org/browse/JBEHAVE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-364. -- Resolution: Fixed Ensure ExamplesTable preserves ordering of columns -- Key: JBEHAVE-364 URL: http://jira.codehaus.org/browse/JBEHAVE-364 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Currently the ExampleTable does not guarantee order of the columns since the row is returned as a HashMap. In some cases, the preserving the order of the textual table may be useful in the implementation of the step. Using LinkedHashMap would preserve the ordering, at a small cost of performance. -- 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-364) Ensure ExamplesTable preserves ordering of columns
[ http://jira.codehaus.org/browse/JBEHAVE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-364: - Description: Currently the ExampleTable does not guarantee order of the columns since the row is returned as a HashMap. In some cases, the preserving the order of the textual table may be useful in the implementation of the step. Using LinkedHashMap would preserve the ordering, at a small cost of performance. was: Currently the ExampleTable does not guarantee order of the columns since the row is returned as a Map. In some cases, the preserving the order of the textual table may be useful in the implementation of the step. Summary: Ensure ExamplesTable preserves ordering of columns (was: Order-preserving ExamplesTable) Ensure ExamplesTable preserves ordering of columns -- Key: JBEHAVE-364 URL: http://jira.codehaus.org/browse/JBEHAVE-364 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Currently the ExampleTable does not guarantee order of the columns since the row is returned as a HashMap. In some cases, the preserving the order of the textual table may be useful in the implementation of the step. Using LinkedHashMap would preserve the ordering, at a small cost of performance. -- 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-369) Allow processing of system processing before stories are run
[ http://jira.codehaus.org/browse/JBEHAVE-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-369. -- Resolution: Fixed Allow processing of system processing before stories are run Key: JBEHAVE-369 URL: http://jira.codehaus.org/browse/JBEHAVE-369 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Some systems used to implement steps may use system properties to control or override their behaviour. E.g. WebDriver system properties to override the default location of the browsers. While system properties may be set at command-line via -D parameters, it is useful to be able to set them via the Embedder and set them before the stories are run. The system properties should also be configurable via Ant or Maven. -- 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-369) Allow processing of system properties before stories are run
[ http://jira.codehaus.org/browse/JBEHAVE-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-369: - Summary: Allow processing of system properties before stories are run (was: Allow processing of system processing before stories are run) Allow processing of system properties before stories are run Key: JBEHAVE-369 URL: http://jira.codehaus.org/browse/JBEHAVE-369 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.1 Some systems used to implement steps may use system properties to control or override their behaviour. E.g. WebDriver system properties to override the default location of the browsers. While system properties may be set at command-line via -D parameters, it is useful to be able to set them via the Embedder and set them before the stories are run. The system properties should also be configurable via Ant or Maven. -- 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
Re: [jbehave-dev] Re: TAG support in JBehave
I tried running like this:
public Configuration configuration() {
Class? extends Embeddable embeddableClass = this.getClass();
*Embedder embedder = new Embedder();*
* **embedder.useMetaFilters((asList(+UseCase *)));*
* **useEmbedder(embedder);*
return new MostUsefulConfiguration()
.useStoryLoader(new LoadFromClasspath(embeddableClass))
.useStoryReporterBuilder(
new StoryReporterBuilder()
.withCodeLocation(
CodeLocations
.codeLocationFromClass(embeddableClass))
.withDefaultFormats()
.withFormats(Format.CONSOLE, Format.TXT,
Format.HTML, Format.XML));
}
but when i executed the story, it says the following in console, which I
cant comprehend.
*Meta[properties={}] not allowed by filter '+UseCase *'*
What am I doing wrong?
On Wed, Oct 20, 2010 at 2:02 PM, Tahir Raza tahirr...@gmail.com wrote:
Mauro,
I am excited to use Tags!! Not exactly sure if I follow how to configure it
yet. Im still learning jbehave.
Looking at code below, how do I configure the usage of tags.
In our GlobalStories class that extends JUnitStories, we have the
following. (class is also attached)
*
*
*Thanks for the help man!*
*
*
*...@override*
* **public Configuration configuration() {*
* **Class? extends Embeddable embeddableClass = this.getClass();** *
* **return new MostUsefulConfiguration()*
* **.useStoryLoader(new LoadFromClasspath(embeddableClass))*
* **.useStoryReporterBuilder(*
* **new StoryReporterBuilder()*
* **.withCodeLocation(*
* **CodeLocations*
* **.codeLocationFromClass(embeddableClass))*
* **.withDefaultFormats()*
* **.withFormats(Format.CONSOLE, Format.TXT,*
* **Format.HTML, Format.XML));*
* **}*
On Tue, Oct 19, 2010 at 7:28 AM, Mauro Talevi
mauro.tal...@aquilonia.orgwrote:
Tahir,
3.1-beta-1 now supports meta info, which can be use to filter or map
stories:
http://jbehave.org/reference/preview/meta-info.html
As always, feedback is welcome.
Cheers
On 05/10/2010 15:58, Tahir Raza wrote:
Thank you Mauro!
On Mon, Oct 4, 2010 at 5:09 PM, Mauro Talevi
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org wrote:
The behaviour of the meta-info is actually meant to be very generic
and user-definable, i.e. you'll be able to define your own tags to
your liking.
The story has not been implemented yet, but OTOH I don't see as
particularly tricky or difficult. It's been getting increasingly
requested so it's likely to be the next one to get done. You may
expect a beta later this month.
Cheers
On 04/10/2010 22:38, Tahir Raza wrote:
Thanks for the prompt reply Mauro!
Here is what I see getting implemented:
* A way to indicate the Author(s) of a scenario
* A way to indicate the Owner of a story
* A way to indicate the Creation Date of a scenario
* A way to indicate the Last Update Date of a scenario
* The injection phase of the scenario (eg. grooming, planning,
development...)
So if I were to use these tags, correct me please if I am wrong,
most likely I am going to use the *injection *tag and use it
according to what I earlier asked? Or are we going to have a
separate way to TAG scenarios like I mention earlier.
2nd Question, when do you think 3.1 is getting released. Like Beta
or Stable, if you have an idea.
Thanks!
Tahir
On Mon, Oct 4, 2010 at 4:26 PM, Mauro Talevi
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org wrote:
It's slated for next release (3.1):
http://jira.codehaus.org/browse/JBEHAVE-220
On 04/10/2010 22:24, Tahir Raza wrote:
Hello,
We are following BDD in our projects and have been using
Cucumber/Cuke4Duke stuff for past 3 months.
We just started to implement JBehave and check its features.
*My question is, do you guys know if we have some TAG
features in JBehave, like we have it in Cucumber
*eg: http://github.com/aslakhellesoy/cucumber/wiki/tags
*...@billing*
Feature: Verify billing
@important
Scenario: Missing product description
.
Scenario: Several products
These tags can be defined Dynamically in the step definitions
file rather than Java file. The particular Tagged Scenarios
can be invoked from Maven rather than running all the
scenarios.
Do you know how we can achieve the same behavior in JBehave.
Your response will be highly appreciated.
--
Regards,
Tahir Raza
--
Regards,
Tahir Raza
--
Regards,
Tahir Raza
--
Regards,
Tahir Raza
-
To unsubscribe from this
Re: [jbehave-dev] Re: TAG support in JBehave
This is my Scenario:
Scenario: The objective of the test case is to verify that the 3rd Party
product offerings page functions as expected. (PREPPOSFN01)
Meta: @UseCase My first use case
Given I access the site
And I am an anonymous user
When I click on the Apply Now link
Then I should see text Already have a Best Buy Credit Card account? on the
page
And page title should be Credit Cards
Still getting the message:
Meta[properties={}] not allowed by filter '+UseCase'
Not sure what I am missing.
On Wed, Oct 20, 2010 at 3:09 PM, Mauro Talevi mauro.tal...@aquilonia.orgwrote:
The message below means that it has not found any story or scenario that
matched the meta info.
Have you add it to your stories or scenarios? You'll need to have
something like:
Scenario:
Meta: @UseCase My first use case
In terms of configuration, it's better to keep the Configuration separate
from the Embedder. Have a look at:
http://git.codehaus.org/gitweb.cgi?p=jbehave-core.git;a=blob;f=examples/trader/src/main/java/org/jbehave/examples/trader/TraderStory.java
In the constructor you can specify the meta filters on the Embedder.
Or you may consider specifying the them via the Maven (or Ant, similarly).
http://git.codehaus.org/gitweb.cgi?p=jbehave-core.git;a=blob;f=examples/trader/pom.xml
Or even via annotations:
http://git.codehaus.org/gitweb.cgi?p=jbehave-core.git;a=blob;f=examples/trader/src/main/java/org/jbehave/examples/trader/AnnotatedTraderEmbedder.java
On 20/10/2010 21:21, Tahir Raza wrote:
I tried running like this:
public Configuration configuration() {
Class? extends Embeddable embeddableClass = this.getClass();
*Embedder embedder = new Embedder();*
* **embedder.useMetaFilters((asList(+UseCase *)));*
* **useEmbedder(embedder);*
return new MostUsefulConfiguration()
.useStoryLoader(new LoadFromClasspath(embeddableClass))
.useStoryReporterBuilder(
new StoryReporterBuilder()
.withCodeLocation(
CodeLocations
.codeLocationFromClass(embeddableClass))
.withDefaultFormats()
.withFormats(Format.CONSOLE, Format.TXT,
Format.HTML, Format.XML));
}
but when i executed the story, it says the following in console, which I
cant comprehend.
*Meta[properties={}] not allowed by filter '+UseCase *'*
What am I doing wrong?
On Wed, Oct 20, 2010 at 2:02 PM, Tahir Raza tahirr...@gmail.com wrote:
Mauro,
I am excited to use Tags!! Not exactly sure if I follow how to configure
it yet. Im still learning jbehave.
Looking at code below, how do I configure the usage of tags.
In our GlobalStories class that extends JUnitStories, we have the
following. (class is also attached)
*
*
*Thanks for the help man!*
*
*
*...@override*
* **public Configuration configuration() {*
* **Class? extends Embeddable embeddableClass = this.getClass();** *
* **return new MostUsefulConfiguration()*
* **.useStoryLoader(new LoadFromClasspath(embeddableClass))*
* **.useStoryReporterBuilder(*
* **new StoryReporterBuilder()*
* **.withCodeLocation(*
* **CodeLocations*
* **.codeLocationFromClass(embeddableClass))*
* **.withDefaultFormats()*
* **.withFormats(Format.CONSOLE, Format.TXT,*
* **Format.HTML, Format.XML));*
* **}*
On Tue, Oct 19, 2010 at 7:28 AM, Mauro Talevi mauro.tal...@aquilonia.org
wrote:
Tahir,
3.1-beta-1 now supports meta info, which can be use to filter or map
stories:
http://jbehave.org/reference/preview/meta-info.html
As always, feedback is welcome.
Cheers
On 05/10/2010 15:58, Tahir Raza wrote:
Thank you Mauro!
On Mon, Oct 4, 2010 at 5:09 PM, Mauro Talevi
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org wrote:
The behaviour of the meta-info is actually meant to be very generic
and user-definable, i.e. you'll be able to define your own tags to
your liking.
The story has not been implemented yet, but OTOH I don't see as
particularly tricky or difficult. It's been getting increasingly
requested so it's likely to be the next one to get done. You may
expect a beta later this month.
Cheers
On 04/10/2010 22:38, Tahir Raza wrote:
Thanks for the prompt reply Mauro!
Here is what I see getting implemented:
* A way to indicate the Author(s) of a scenario
* A way to indicate the Owner of a story
* A way to indicate the Creation Date of a scenario
* A way to indicate the Last Update Date of a scenario
* The injection phase of the scenario (eg. grooming, planning,
development...)
So if I were to use these tags, correct me please if I am wrong,
most likely I am going to use the *injection *tag and use it
according to what I earlier asked? Or are we going to have a
separate way to TAG scenarios like I mention earlier.
2nd Question, when do you think 3.1 is getting released. Like Beta
or Stable, if you have an idea.
Thanks!
[jbehave-dev] [jira] Resolved: (JBEHAVE-371) Leading and trailing spaces in example table cells are removed
[
http://jira.codehaus.org/browse/JBEHAVE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-371.
--
Resolution: Fixed
Leading and trailing spaces in example table cells are removed
--
Key: JBEHAVE-371
URL: http://jira.codehaus.org/browse/JBEHAVE-371
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.0.3
Reporter: Frank Grimm
Priority: Minor
In JBehave Core 3.0.3 all leading and trailing spaces are removed from
example table cells.
For example, when accessed through the ExamplesTable API (the following table
{code}
| |A | B | C|
| |X | Y | Z|
{code}
becomes
{code}
||A|B|C|
||X|Y|Z|
{code}
Leading/trailing spaces were not removed for JBehave Core versions older than
3.0.3. So, it might be a regression cause when this
http://jira.codehaus.org/browse/JBEHAVE-353 was fixed.
At least for me it would be nice to be able to use example tables containing
cells with leading/trailing 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-371) Allow leading and trailing spaces to be preserved in example table cells
[
http://jira.codehaus.org/browse/JBEHAVE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-371:
-
Issue Type: Improvement (was: Bug)
Summary: Allow leading and trailing spaces to be preserved in example
table cells (was: Leading and trailing spaces in example table cells are
removed)
Allow leading and trailing spaces to be preserved in example table cells
Key: JBEHAVE-371
URL: http://jira.codehaus.org/browse/JBEHAVE-371
Project: JBehave
Issue Type: Improvement
Components: Core
Affects Versions: 3.0.3
Reporter: Frank Grimm
Assignee: Mauro Talevi
Priority: Minor
Fix For: 3.1
In JBehave Core 3.0.3 all leading and trailing spaces are removed from
example table cells.
For example, when accessed through the ExamplesTable API (the following table
{code}
| |A | B | C|
| |X | Y | Z|
{code}
becomes
{code}
||A|B|C|
||X|Y|Z|
{code}
Leading/trailing spaces were not removed for JBehave Core versions older than
3.0.3. So, it might be a regression cause when this
http://jira.codehaus.org/browse/JBEHAVE-353 was fixed.
At least for me it would be nice to be able to use example tables containing
cells with leading/trailing 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-scm] jbehave-core branch, master, updated. jbehave-3.1-beta-2-4-gd3e0922
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project jbehave-core.
The branch, master has been updated
via d3e09228df0abea571d35e557d535eabb04fa113 (commit)
from 58240630017629d3672781e79942186028564b58 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit d3e09228df0abea571d35e557d535eabb04fa113
Author: Mauro Talevi mauro.tal...@aquilonia.org
Date: Thu Oct 21 00:46:39 2010 +0200
JBEHAVE-371: Allowed twhitespace to be preserved in column values via the
{trim=false} optional property.
---
Summary of changes:
.../java/org/jbehave/core/model/ExamplesTable.java | 87 +---
.../jbehave/core/model/ExamplesTableBehaviour.java | 31 +++
2 files changed, 106 insertions(+), 12 deletions(-)
hooks/post-receive
--
jbehave-core
hr/
p
To unsubscribe from this list please visit:
/p
p
a
href=http://xircles.codehaus.org/manage_email;http://xircles.codehaus.org/manage_email/a
Re: [jbehave-dev] Re: TAG support in JBehave
On 20/10/2010 22:55, Tahir Raza wrote:
This is my Scenario:
Scenario: The objective of the test case is to verify that the 3rd
Party product offerings page functions as expected. (PREPPOSFN01)
Meta: @UseCase My first use case
Given I access the site
And I am an anonymous user
When I click on the Apply Now link
Then I should see text Already have a Best Buy Credit Card account?
on the page
And page title should be Credit Cards
Still getting the message:
Meta[properties={}] not allowed by filter '+UseCase'
Not sure what I am missing.
Sorry, my fault: to match a meta filter with a non-blank value, you
need a filter that either provide an exact match of the value (e.g.
'+UseCase My first use case') or one that matches using the * pattern
(e.g. '+UseCase *' or '+UseCase * use case').
More documentation will be available soon.
[jbehave-scm] jbehave-web branch, master, updated. jbehave-web-3.1-beta-2-9-g91334ec
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project jbehave-web. The branch, master has been updated via 91334ec3502c482b3357cf6905fdb0676cdb0aec (commit) from d796f66a15c3086a24c3086df58ee449617cd2ba (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 91334ec3502c482b3357cf6905fdb0676cdb0aec Author: Mauro Talevi mauro.tal...@aquilonia.org Date: Thu Oct 21 00:59:40 2010 +0200 Fixed generics warning. --- Summary of changes: .../jbehave/web/runner/wicket/pages/Template.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- jbehave-web hr/ p To unsubscribe from this list please visit: /p p a href=http://xircles.codehaus.org/manage_email;http://xircles.codehaus.org/manage_email/a
