Joe Walnes wrote:
Just to clarify - is the scope of assemble() to avoid big constructors
or is there another usecase for it?
That's definitely one of the reasons.
Another is to allow the API to evolve over time without necessarily
breaking people's code when a new dependency is
Dan North wrote:
Troops,
I've been thinking long and hard about this, and I've made a decision.
The JBehave website is old and tired and dull. Even with Shane's swanky
new builder, we still end up with a static website with not much going on.
Here's what I want from a website:
* *Easy to
Felix Leipold wrote:
Hi Dan,
The eclipse plugin should be working again. I checked in a bugfix and loads
of buildscripts, that are actually producing an update site.
How to trigger a build:
There is a build.xml in the jbehave\plugins directory.
If your eclipse lives in C:\Program
Felix Leipold wrote:
As Mauro proposed I moved all eclipse specific stuff to plugins/eclipse and
renamed the feature and plugin folder to comply with eclipse naming
conventions.
Cool! I was looking at build.xml - don't you need to specify ${label} as well,
eg
ant
[EMAIL PROTECTED] wrote:
[EK] Removed Cotta, fixed ClassMocks which had not been added to build and
therefore got broken.
Mauro - I removed the plugins from .classpath due to missing jar; please fix!
Ta!
Liz - I've added maven-plugin-api to .classpath. That should allow you to compile in
Elizabeth Keogh wrote:
It may be time for a 1.0.1 release. I've fixed a few bugs and added a
couple of features which were desperately needed for running the Story
framework on a commercial project.
IMO - new features should require a 1.1 release, while for bugfixes only a
1.0.1 is
Hi Dan,
Dan North wrote:
Hi folks.
I've been following an interesting discussion about evolving APIs, and
there's something I'd like to do for jbehave 1.1.0. Technically it
should be jbehave 2.0.0 by my own definitions, in that it will break
existing client code, so I want to get it out
Dan North wrote:
Hi team.
Can everyone kick the tyres on 1.1.0 please? That's the download links
on the website (I've already checked but I'm paranoid), the javadocs
(ditto), the eclipse and idea plugins, and any implied or otherwise
promises to address world hunger. If all is well I'll
Dan North wrote:
So it occurred to me that a) we haven't really changed anything in
jbehave since 1.0.0, just got the stuff working (eclipse plugin in OSX,
idea plugin anywhere) that should have been there in the first place.
Plus we get to make a fanfare about the jbehave 1.0 release.
So
Elizabeth Keogh wrote:
Hi all,
I'm trying to add Collection and Array matchers to UsingMatchers.
This is now a really, really big class!
I'd like to split it up and delegate to the package-accessible splits,
because this will make it easier to maintain.
The split I envisage at the moment
Elizabeth Keogh wrote:
Hi all,
You know the ethics of release better than I do.
Is it OK to deprecate classes, if I don't actually remove them prior to
2.0?
Deprecated classes don't need to wait necessarily until major release to be removed, ie can be
removed at release 1.n if it
Hi Eric
Eric Lewin wrote:
Hi!
I was thinking that starting with JBehave would be something like this:
1. writing story text files with the customer
2. Generating the code for givens, event and outcomes with Ensure.pending()
3. Run the story textfile
4. Implement some givens, event and outcomes
Eric Lewin wrote:
Hi,
I prefer to discuss the stories/scenarios with my customer before
coding, so I've rewritten the StoryGeneratorSpike so that it works as
described in feature suggestion #2 further down.
Are you interested in that code?
Sure - I understand your point of view and it's
Stefan Hübner wrote:
So this would boil down to placing behaviours/stories either in
src/main/java or src/test/java and scoping jbehave either in
compile or test scope.
The switch could be easily supported by a simple boolean configuration
option, I guess. The plugin then would create a
Stefan,
sorry for the long wait - getting back to jBehaving ...
Stefan Hübner wrote:
So this would boil down to placing behaviours/stories either in
src/main/java or src/test/java and scoping jbehave either in
compile or test scope.
The switch could be easily supported by a simple boolean
Hi,
a velocity-based code generator has been added to the jBehave core
http://jira.codehaus.org/browse/JBEHAVE-94
Requires two input params: story source directory and story package name.
See behaviour for details:
Hi,
for folks interested in using jBehave via the Maven plugin, a number of improvements and bugfixes
have been implemented, as also suggested previously on the list:
Hi Liz,
Elizabeth Keogh wrote:
Hi Mauro,
I can see you're working on my favourite thing - the stuff that turns
stories into code automatically.
an itch that had to be scratched :-)
Ryan has volunteered to help us with JBehave, and I foolishly suggested
he might help without realising you
Elizabeth Keogh wrote:
Any chance we can get these code generation stories in before 1.1?
+1 for code generation before 1.1 but we can still release a 1.1-beta-1 with only some of them
implemented. See reply to other email.
My help is available weekends...
Ok - have a look at what's
Elizabeth Keogh wrote:
Hi all,
I found the bug in the story printing (it was minor) and have now added
run-example-stories and print-example-stories to the default ant build.
These should work in headless mode too (they throw pending exceptions).
Cools - it seems that the only
Shane Duan wrote:
As part of the work of making a GUI IDEA plugin for jBehave, I think I need
to do some changes on the jBehave core:
* Get rid of verifier field. There are a bit of code handling this field, yet
the only place it is being passed in is from the behaviors of the
classes
Shane Duan wrote:
On 8/29/07, Mauro Talevi [EMAIL PROTECTED] wrote:
Shane Duan wrote:
As part of the work of making a GUI IDEA plugin for jBehave, I think I need
to do some changes on the jBehave core:
* Get rid of verifier field. There are a bit of code handling this field, yet
the only
Dan North wrote:
Hi chaps.
Shane, can you make your proposed change in a branch please and post us
the svn url so Mauro can pick it to pieces? :)
That'd work. Or posting a patch would work as well.
I'm off for weekend though, so I wouldn't get my chopsticks to it before next
week!
Cheers
Hi all,
just a heads up to say that I've cleaned up story printer and runner to:
- use StoryLoader as central point of story loading, both from class name and
from rendered story,
backward compatible with default ctors of StoryPrinter/Runner using the
text-based StoryLoader.
- tucked in all
Elizabeth Keogh wrote:
news [EMAIL PROTECTED] wrote on 03/10/2007
17:17:16:
Liz,
...
If needed an Ant task is easy to mirror.
Would you mind terribly doing this for me please, Mauro?
I'm sure I'll convert to Maven at some point, but right now the learning
curve is more than I have
Dan North wrote:
On a personal note, I'd like to develop it using mercurial rather than
subversion, having discovered that moving from centralised to
distributed source control is almost as liberating as having source
control in the first place. So in terms of logistics, we would keep
Dan North wrote:
I'd like to second his suggestion that those of us who are
co-located should get together occasionally for a pint and a chat
(next week, anyone?). I'm also on Skype and Yahoo, and have a mobile
phone.
Beer is good. I'm not around next week but the week after
Dan North wrote:
Git is a non-starter because it doesn't run on windows and only just
works on OSX (it's a bunch of shell scripts). A purely non-scientific
poll put mercurial ahead of darcs, because a couple of people I trust
prefer it (Joe being one of them) and because it's written in
Elizabeth Keogh wrote:
Mauro wrote on 09/11/2007 10:39:18:
I do think toy and example apps can be very useful but as an
complement rather than a substitute for unit/behaviour testing.
Absolutely! I was thinking of the toy projects as the equivalent of
stories and automated scenarios - it
Hi all,
as detailed in http://jira.codehaus.org/browse/JBEHAVE-132, I've
refactored the base Scenario class along these lines:
- Extracted Scenario interface and provided AbstractScenario impl.
- Renamed Scenario - JUnitScenario (which now supports both JUnit 4.x
and JUnit 3.x) which is a
Dan North wrote:
Hi folks.
When we designed JBehave 2 we made some assumptions and left some
deliberate gaps.
One of the assumptions was that people would run scenarios using JUnit
4. They would then use whichever mocking framework they want - JMock,
EasyMock and Mockito being the three
Mauro Talevi wrote:
Apart from the rename of Scenario - I had already gone through this
process (see previous email I sent, in which I posed the issue of the
backward compat).
So, seeing that backward compat is deemed more important (and I do not
disagree) I've now renamed Scenario interface
Dan North wrote:
Ooh! I like the idea of leaving Scenario as the default abstract class,
under JUnitScenario (so effectively it's just an alias for it).
Ok - so you're saying we should un-deprecate it as leave it as a default
alias?
Not against an alias class, but perhaps I would name
Mauro Talevi wrote:
I've made a couple of fixes that I'd like to push out as 2.0.1:
http://jira.codehaus.org/browse/JBEHAVE/fixforversion/14549
These changesets are now merged in 2.1 trunk as well.
Cheers
-
To unsubscribe
Dan North wrote:
Is there anything else we want to add to a 2.0.1 release?
We have now cunningly inserted JUnitScenario as a superclass to
Scenario, which provides a hook for OtherKindsOfScenario (thanks Mauro),
and cleaned up some Windows weirdness (again, thanks Mauro).
Dan,
ATM only the
Mauro Talevi wrote:
ATM only the windows issues have been addressed in branch 2.0.x.
The support for multiple test frameworks
(http://jira.codehaus.org/browse/JBEHAVE-132) is in trunk scheduled for
2.1 release.
Changesets 930-933 could be merged to 2.0.x branch although it not being
JBehave 2.0.1 has been released with following changelog:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10680fixfor=14549
Releases available from http://jbehave.org/software/download
Cheers
-
To
Elizabeth Keogh wrote:
I don't want to mark this as fixed yet because our Ant build is
broken following the PicoContainer and Spring work. Dan and I are
about to Ivy the build anyway, which will help us resolve these
dependencies. Everything else is working.
Great - could we then remove the
Liz,
just a minor afterthought - could these annotations be expressed
equivalently as
@AfterScenario(success=true/false)
and if success is omitted then it defaults to @AfterScenario behaviour.
Like?
-
To unsubscribe from
[EMAIL PROTECTED] wrote:
On Oct 16, 2008 9:26pm, Mauro Talevi
[EMAIL PROTECTED] wrote:
Liz,
just a minor afterthought - could these annotations be expressed
equivalently as
@AfterScenario(success=true/false)
and if success is omitted then it defaults to @AfterScenario behaviour
Dan North wrote:
So who are you ...
I'm Mauro, and I've been involved with JBehave it's pre-1.0 days when
Dan took it out of hibernation (It's something I've been playing with
on and off for a while but it needs to be pushed out and released, he
said). I was looking for a tool to replace
The team is proud to announce the release of JBehave 2.1.
Announcement: http://jbehave.org/2008/10/25/jbehave-21-released/
Changelog:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10680fixfor=14547
Download: http://jbehave.org/software/download/
Cheers
Liz,
have a look if the current implementation in trunk satisfies the use
case you had in mind.
I also updated trader example to use aliases.
Cheers
-
To unsubscribe from this list, please visit:
Laura Vendramini wrote:
Hi,
I am trying to develop with JBehave. I am using Eclipse Classic
3.4.1, JDT 3.4, JBehave Version 2.1.
When I try to run the behavioral tests, it always says that The
Source Not Found ... The source attachment does not contain the
source for the file
aslak hellesoy wrote:
Hi gang,
With a little JRuby love I managed to hook Cucumber (http://cukes.info/)
up to JBehave. My latest commit:
http://github.com/aslakhellesoy/cucumber/commit/855e033832e19b5ad248c57cfb4abc8f72fa2da0
What this means is that it will be possible to use Cucumber with
JBehave 2.1.1 has been released with following changelog:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10680fixfor=14933
Releases available from http://jbehave.org/software/download
Cheers
-
To
Laura Vendramini wrote:
Hi,
I would like to help in the development of JBehave. I am working on
a large project right now that needs scenariosand their status to be
outputted (whether they passed, failed, or are pending) using Mavin 2.
I'd like to contribute to getting this accomplished.
aslak hellesoy wrote:
On Fri, Jan 23, 2009 at 2:16 PM, aslak hellesoy
aslak.helle...@gmail.com
mailto:aslak.helle...@gmail.com wrote:
On Fri, Jan 23, 2009 at 1:02 PM, Mauro Talevi
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org wrote:
aslak
Laura Vendramini wrote:
Thanks Mauro,
Where do I access the code? The site is down so I can't access it?
Is there anything I need to sign up for or download?
Just use anonymous access as detailed in
http://jbehave.org/software/source-repository/
Site seems to up now, but in any case the
aslak hellesoy wrote:
Oops sorry that's not correct. Looks like a JRuby bug.
What jruby version do you have? You should use the latest version (1.1.6)
Okokokokok. I didn't get enough sleep. I see you have a really old
JRuby version. Just upgrade and you should be fine.
Indeed it worked.
Laura Vendramini wrote:
I was finally able to download the truck off svn.
I had installed svn but still wasn't able to access the svn command,
so I found this website and it walks you though step by step to set
everything up.
http://www.wishingline.com/notebook/2007/03/installsvnmacosx/
In the
Laura Vendramini wrote:
Hey,
Is there a way to output to a file (using maven 2) exactly what is
printed in the console?
Just configure the scenarios to use a PrintStreamScenarioReporter with
an appropriate instance of PrintStream, eg by extending the default
configuration:
new
Laura Vendramini wrote:
Thanks Mauro,
new PrintStream(new File(/path/to/your/output)) did not work, but
the below was able to output to a file...
public ScenarioReporter forReportingScenarios() {
PrintStream ps=null;
// Connect print stream to the output stream
try {
Folks,
a new web-integration project - JBehave Web - has been added.
http://jbehave.org/documentation/web-integration/
JBehave Web is intended as a separate project - with its own release
lifecycle - that builds on JBehave core.
Be aware that the svn layout has changed accordingly.
Trunk
Laura Vendramini lvend...@... writes:
Hey,
I've attached a screen shot of jBehave's passing and failing tests on
the codehaus website. This is exactly what I need to be outputted,
but instead of using codehaus, I am using Maven 2. How are the
passing and failing scenarios displayed
Paul Hammant p...@... writes:
http://fisheye.codehaus.org/changelog/jbehave/?cs=1118
Pual, I think this page
http://jbehave.org/documentation/regex-stack-overflow-errors/
would be better placed under FAQ or under a /known-issues parent page.
Also, it'd be good if we added the link to the
Dan North tasta...@... writes:
Maybe invert it and call it Constraint.
But it's not clear to me what the use case of this Context/Constraint is.
I mean if it's only descriptive, then Scenario should suffice. Remember that you
can have a scenario description over as many lines as you need and
Paul Hammant p...@... writes:
No, Context (as I suggested) was executable in a steps class.
at Context( once for each browser/os)
super.getContext().replaceScenarioExecutor(execr);
}
at Context( once for each browser/os in parallel)
public void eachBrowserInParallel()
Ed Bowler wrote:
Hi,
I'm having trouble debugging my jbehave tests. I cannot get maven to
start the jbehave tests and stop at a breakpoint. I have this in my pom:
pluginManagement
plugins
plugin
groupIdorg.jbehave/groupId
artifactIdjbehave-maven-plugin/artifactId
Ed Bowler wrote:
Mauro Talevi wrote:
any reason you can't debug your scenarios running them as JUnit tests
in your favourite IDE?
The the execution doesn't stop at a breakpoint in the IDE (netbeans) for
jbehave scenarios, but does for junit tests. So I was trying from the
command line, since
Folks,
I've committed a refactor that deals with the regex stack overflow
problem on Windows. It is backward compatible.
I've deployed snapshot with the refactor. Please try it out on your
project, if you ever encountered the problem to verify if it fixes it.
If no problems are
Renjitha K wrote:
HI Development team,
Can someone please tell me how we can generate an HTML report for JBehave?
It seems to be very minimal. How can we add more detail to it?
Thanks
Renjitha
Hi Renjita,
ATM there is no such functionality (I've added a new issue for it
The team is proud to announce the release of JBehave 2.2.
Announcement: http://jbehave.org/2009/04/24/jbehave-22-released/
Changelog:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10680fixfor=14670
Download: http://jbehave.org/software/download/
Cheers
Hi Emerson,
we agree that I18n is an essential feature of BDD, as the scenario
functionality needs to read well in the language of the business.
That is why JBehave supports it via configurable keywords.
What you're proposing is nonetheless useful (having different language
keywords
Folks,
I've published 2.0-rc1 of JBehave Web release, which provided an web
integration layer on top of JBehave Core. The main objective of this
layer is to provide a simple web-based interface to running scenarios. A
typical use case of this is when non-developers (e.g. BAs/QAs) need to
?
Cheers,
Dan
2009/8/9 Mauro Talevi
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org
Folks,
I've published 2.0-rc1 of JBehave Web release, which provided an web
integration layer on top of JBehave Core. The main objective of
this layer is to provide a simple web
Dan North wrote:
Hi Dan,
they actually address very different concerns.
Ah, fantastic. My stupid. As you were, troops.
Cool, I'll cut release on weekend then.
Cheers
-
To unsubscribe from this list, please
The team is proud to announce the release of JBehave Web 2.0.
Announcement: http://jbehave.org/2009/08/20/jbehave-web-2-0-released/
Download: http://jbehave.org/software/download/
Cheers
-
To unsubscribe from this list,
Elizabeth Keogh wrote:
On Wed, Sep 2, 2009 at 12:49 AM, aslak hellesoyaslak.helle...@gmail.com wrote:
Hi!
I have rounded up some fine folks who are working on a new, fast parser
(based on Ragel) for Gherkin - the language that Cucumber supports.
Since Gherkin is a superset of what JBehave
aslak hellesoy wrote:
There is no formal specification except the treetop grammar inside
cucumber. There is a wiki page on Gherkin in the Cucumber wiki (written
by someone I don't know) and it's terrible. I won't even link to it ;-)
I hope to produce a BNF as part of the Gherkin project.
Cristiano Gavião wrote:
Hi Mauro,
I am testing your implementation for I18n for portuguese language and I
found some issues.
First, the class I18nKeywordsBehaviour has some problems with words that
has graphical caracter as Cenário. There is a know issue that happens
with Latin laguages:
to you and all jbehave team
for the EXCELLENT job..
Its really an amazing tool
best regards
Cristiano
Mauro Talevi escreveu:
Cristiano Gavião wrote:
Hi Mauro,
I am testing your implementation for I18n for portuguese language and
I found some issues.
First, the class
Cristiano Gavião wrote:
Another problem I could see is that there is a encode problem with your
keywords_pt_properties file. The problem is exatly the one that I tried
to warn you on my last email: Your file was saved on ISO8859-1(windows)
but containing UTF-8 way portuguese caracters. Im
Mauro Talevi wrote:
Cristiano,
yes, I too had become aware of this issue as I was preparing a fully
i18n-ed example. I'm working to get the StepsConfiguration use the
KeyWords to get the starting words. There should only be one place
where these keywords are defined, although here
Cristiano Gavião wrote:
Hi Mauro,
I'll do this until next weekend ok?
Sure, Cristiano, whenever you have time. In the meantime, we'll
probably cut a RC for people to try out new features.
Cheers
-
To unsubscribe from
the Brazilian Portugue Trader Example.
Cheers
Cristiano
Mauro Talevi escreveu:
Cristiano Gavião wrote:
Hi Mauro,
I'll do this until next weekend ok?
Sure, Cristiano, whenever you have time. In the meantime, we'll
probably cut a RC for people to try out new features.
Cheers
Mauro Talevi wrote:
Cristiano Gavião wrote:
Mauro Talevi escreveu:
Cristiano Gavião wrote:
Sorry, I think I got wrong project and did wrong export process...
Living and Learning... :-)
It was the first time that I did a svn patch, let me know if it's ok
now.
it was my pleasure
The team is proud to announce the release of JBehave Web 2.1.
Announcement: http://jbehave.org/2009/10/11/jbehave-web-2-1-released/
Changelog: http://jira.codehaus.org/browse/JBEHAVE/fixforversion/15720
Download: http://jbehave.org/software/download
Reference:
Cristiano Gavião wrote:
Hi Mauro,
Im using selenium and I've made a LOGIN scenario where I can setup a
session with some context variables that will be used for all application.
So I am using Given Scenarios to reuse it across all other scenarios on
my system test...
But my strategy is
Elizabeth Keogh wrote:
Hi Ravi,
A quick google ( searched for hudson java.lang.NoClassDefFoundError:
org/apache/log4j/Category) suggests it's an issue with Maven and
Hudson, rather than JBehave. I'm not familiar with Maven (that's
Mauro's baby!) but see if this helps:
Ravi Varanasi wrote:
Mauro -
Though the exception is thrown only when the run-scenarios is run (bound to
integration-test phase). If the scenarios are not run the test works fine.
Below is the output from dependency tree
[INFO] +- org.springframework:spring-core:jar:2.5.6:compile
[INFO] | \-
Ravi Varanasi wrote:
Mauro -
Below are the answers -
Hi Ravi,
let's take in steps:
1. Can you run scenarios successfully using Maven in CLI on your local
machine - but not embedded in Hudson or any other CI?
Running the scenarios from command line through Maven works, but running inside
Ravi Varanasi wrote:
Mauro -
One of the team members found a workaround for this problem. The problem is
commons-logging vs slf4j class loader issues. I think spring brings in the
slf4j dependency in our project.
Adding
Mauro Talevi wrote:
Ravi Varanasi wrote:
P.S. I was unable to build the JBehave src project. Are all the tests
passing ?
I tried to check out the bamboo build and it is been red for a long
time. Is
this an issue ?
It builds fine on my end, with following configuration:
Apache Maven 2.2.0
Hi Cristiano,
the first step to understanding where what's going on is to enable the
step monitoring. By default, the silent step monitor is used. Change
the StepConfiguration to use the PrintStreamStepMonitor.
If you can't get any joy, feel free to send a sample of your steps.
Cheers
Cristiano Gavião wrote:
Hi Mauro,
Im thinking here...
Would be possible to combine Table Parameters and Table Examples?
Given your example:
|Given| |the traders: |
name|rank| |
Larry|Stooge 3| |
Moe|Stooge 1| |
Curly|Stooge 2| |
|||When| |a wildcard search .*y is executed |
Thanks Cristiano, patch applied:
http://jira.codehaus.org/browse/JBEHAVE-212
Cristiano Gavião wrote:
Hi Mauro,
I've tried to use a static atribute to retain the StepsConfiguration
private static final StepsConfiguration configuration = new
StepsConfiguration();
And I've used it
Elizabeth Keogh wrote:
Hi all,
Just to let you know, I've come across a bit of an issue in JBehave
2.3.2 and am investigating. The sources appear to have a lot of .svn
files in them. I'm also getting test failures on trunk in the Maven
build and compile failures in the Ant build (running on a
Hi Cristiano,
thanks for the patch. Could you please attach it to the Jira issue to
make it easier to pick up?
I'll try to have a look in the next couple of days.
BTW, can you make sure you use command-line to create patch:
svn diff JBEHAVE-215-patch.txt
Eclipse tends to add the project
Cristiano Gavião wrote:
I'm getting a strange behaviour using Maven Plugin.
When I configure it without a executions node, it works well:
plugin
groupIdorg.jbehave/groupId
artifactIdjbehave-maven-plugin/artifactId
Yes, apart from a unit test, which is now also fixed (the ol' dos2unix
issue). I should now build successfully on Windows.
Cheers
Cristiano Gavião wrote:
Hi,
Was not necessary to disable the feature because your last commit solved
the problem with windows... for now :-)
thanks
Mauro
Folks,
one of the main focuses of 2.4 has been on reporting.
JBehave has always offered the possibility of the plugging in bespoke
reports, via its ScenarioReporter interface, but up to now only the
textual report output was offered out of the box.
From 2.4, it provides an easy and
Hi Cristiano,
rows in the table have no identifier so cannot be named.
If you want to work with an entire row, you can inject the whole table
and retrieve the single rows by row number.
Cheers
Cristiano Gavião wrote:
Hi Mauro,
Is there a way to inject the entire row from a table example as
Cristiano,
the DI support is still very much experimental work we're doing with
Paul. We're still trying to work out some fundamentals and if it's
stable enough to release in 2.4, or need to postpone it to 2.5 (hence
we've not gone public with it). As soon as we've got a stable build
with
Cristiano Gavião wrote:
Hummm... ok
Cold you give some clue or an example how could I inject the whole table
on a method? I've tried to create ExamplesTableConverter but doesnt
works so
I could create a converter that allowed me to put a separated by comma
array list inside some
Shouldn't Windows understand URL encoding of spaces?
I'll look into it a bit more.
Cheers
Cristiano Gavião wrote:
Hi,
Trying to run som example of jbehave with reports and jbehave is
creating another file structure. I've run using junit inside eclipse on
windows xp.
The folders created
Cristiano Gavião wrote:
Hi,
Humm, ok. I already tried some experimental work myself with guice and
jbehave, mostly unsucessfull until now...
But I could get guice to work together with junit, but it was needed to
create an expecific extension of BlockJUnit4ClassRunner..
Btw, I really
Hi all,
a first RC for 2.4 has been released:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10680version=15664
The new features have been primarily focused on reporting, but there a
number of other improvements.
Their use demonstrated by examples, as always.
The RC is
Hi all,
a feature that's been requested for some time is the ability to insert
comments between executable steps (comments where already supported in
the scenario text description or at story level, i.e. before the first
scenario):
http://jira.codehaus.org/browse/JBEHAVE-163
A minor release
Hi all,
Steps class-level dependency injection is now supported in JBehave 2.5:
http://jbehave.org/reference/latest/dependency-injection.html
It supports 3 major containers most widely used (Pico, Spring, Guice).
Each container support is provided via a separate extension module.
The trader
1 - 100 of 2580 matches
Mail list logo
