Hi all,
If you guys are in on this, that makes me happy.
I'd really like this version of JBehave to be driven by its example projects.
Before I added Hellbound to the build I lost key features which I guess people didn't think were used or needed, but which I was using to drive Hellbound, or my Game of Life, or the Sudoku game (eg: the Main method in StoryPrinter disappeared once, and I lost some stuff that made ClassMocks work). We've also added features which I have no way of knowing if I've broken (eg: the Maven extensions) and others which I felt strongly weren't the right way to solve the problem (eg: AllBehaviours).
This is also the reason I'd like to move to a fresh codebase; because I want the features to be driven by tangible need, not because we think that they might be useful, or are 'cool'. I probably won't use mocks, but if someone else wants to create a project that does use them, that would be fantastic.
My biggest frustration with JBehave 1.x has been the feeling that I'm the only one on the team actually using it (if that's not true, I apologise and would love to chat).
I will be happy to provide ideas for projects using web, swing, databases, etc. Maybe we could even collaborate on something big and useful.
I am happy to support (and host, if necessary) continuous builds for JBehave, and for each example project. Checkout http://lunivore.com:8080/dashboard to see JBehave's build (this cruise is a work in progress; I could take it more seriously).
I intend to be more actively despotic on this project. In practice, that means:
- You'll need to persuade Dan or I that a feature's the right way to provide the relevant benefit (preferably with a narrative and an example project that shows how the feature will work; we will be open to such persuasion and I trust Dan's judgement)
- I'll delete code which appears to be redundant (so if it isn't used in an example project, don't rely on it)
- I reserve the right to revert your version if you break the build.
Please do feel free to argue about my own features; I find the arguments often uncover better ways of solving the problem. You also have the right to revert / delete my code if I fall foul of my own rules (it's happened). In all disagreements, the despots' respectful decision is final.
Is that OK with you all?
Cheers,
Liz.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
If you guys are in on this, that makes me happy.
I'd really like this version of JBehave to be driven by its example projects.
Before I added Hellbound to the build I lost key features which I guess people didn't think were used or needed, but which I was using to drive Hellbound, or my Game of Life, or the Sudoku game (eg: the Main method in StoryPrinter disappeared once, and I lost some stuff that made ClassMocks work). We've also added features which I have no way of knowing if I've broken (eg: the Maven extensions) and others which I felt strongly weren't the right way to solve the problem (eg: AllBehaviours).
This is also the reason I'd like to move to a fresh codebase; because I want the features to be driven by tangible need, not because we think that they might be useful, or are 'cool'. I probably won't use mocks, but if someone else wants to create a project that does use them, that would be fantastic.
My biggest frustration with JBehave 1.x has been the feeling that I'm the only one on the team actually using it (if that's not true, I apologise and would love to chat).
I will be happy to provide ideas for projects using web, swing, databases, etc. Maybe we could even collaborate on something big and useful.
I am happy to support (and host, if necessary) continuous builds for JBehave, and for each example project. Checkout http://lunivore.com:8080/dashboard to see JBehave's build (this cruise is a work in progress; I could take it more seriously).
I intend to be more actively despotic on this project. In practice, that means:
- You'll need to persuade Dan or I that a feature's the right way to provide the relevant benefit (preferably with a narrative and an example project that shows how the feature will work; we will be open to such persuasion and I trust Dan's judgement)
- I'll delete code which appears to be redundant (so if it isn't used in an example project, don't rely on it)
- I reserve the right to revert your version if you break the build.
Please do feel free to argue about my own features; I find the arguments often uncover better ways of solving the problem. You also have the right to revert / delete my code if I fall foul of my own rules (it's happened). In all disagreements, the despots' respectful decision is final.
Is that OK with you all?
Cheers,
Liz.
