To discuss with the Werval community, post questions and get answers, join us at freenode, IRC channel
If you have a question and need some answers, ask it on stackoverflow using the
If you found a bug, want to request a new feature or enhancement or would like to contribute to Werval, keep reading.
If you encounter an issue, please report it by creating a new issue with as much detail as you can get.
Before doing so, please search for existing issues and make sure your bug hasn’t been reported yet.
Remember that you can paste programs output, error traces etc.. into the issue and attach log files, screenshots to it. Anything that could allow us to reproduce the bug in order to fix it is welcome!
If you happen to have some coding skills but don’t want to dive into Werval source code, a test-case that reproduce the bug would be awesome.
Feature or enhancement requests are more than welcome. They are as important as bugs as they give the opportunity to discuss what’s in, what’s missing etc…
Simply report them by creating a new issue describing the feature or enhancement you have in mind.
Werval is written using the Java language (but not limited to it, see the F.A.Q). The source code is managed using
git. You’ll need to use theses two technologies for contributing new code to Werval.
Of course, the first step is to build werval from sources.
Once you’re confident the build is working on your computer, you’ll want a convy IDE supporting Java 8. Werval is built using Gradle that is supported by many IDEs, see the Gradle Tooling page at
We accept contributions as Github Pull Requests.
Pull requests let you tell others about changes you’ve pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.
| Development happens on the
If your contribution is related to an existing issue, please follow this Converting github issues into pull-requests guide.
If you want to contribute to the documentation effort, well that’s really good news!
The Werval documentation lies alongside the source code. It is written using the
AsciiDoc format and processed using
AsciiDoctor, here is the User Manual. All you need is a text editor.
|Documentation contribution workflow is the very same as for code contributions, see above.|
The Werval build system generates a HTML version of the documentation. You should start by building Werval from the source, see above.
Once that the build pass on your computer, see the Werval Documentation guide.
See the Writing Werval Modules guide.
We generally uses a Commit-Then-Review policy on most changes. This allows a reasonable high velocity of development.
Courtesy of Vincent Driessen, we borrowed the git-flow branching model.
It looks more complicated than it is. Here are the guidelines;
Never commit to the
master branch while developing!!
develop branch is the equivalent of trunk in subversion.
Any changes that are not trivial, start a feature branch.
The following names are reserved for not feature branches;
Day-to-day development revolves around the
develop branch and it is this branch that you typically clone from our repository if you intend to contribute to Werval itself. If you create a new feature, or make some larger piece of refactoring, then please create a 'feature branch' (see article for details).
hotfix/ branches are for release management only, and doesn’t affect most contributors from a commit perspective.