Notes for developers
Cucumber-JVM is built with Maven.
mvn clean install
File -> Open Project -> path/to/cucumber-jvm/pom.xml
.feature files must be in a folder that IDEA recognises as source or test. You must also tell IDEA to copy your
.feature files to your output directory:
Preferences -> Compiler -> Resource Patterns -> Add `;?*.feature`
If you are writing step definitions in a scripting language you must also add the appropriate file extension for that language as well.
Just load the root
To hack on Cucumber-JVM you need a JDK, Maven and Git to get the code. You also need to set your IDE/text editor to use:
- UTF-8 file encoding
- LF (UNIX) line endings
- No wildcard imports
- Curly brace on same line as block
- 4 Space indent (no tabs)
- 2 Space indent (no tabs)
Please do not add @author tags - this project embraces collective code ownership. If you want to know who wrote some code, look in git. When you are done, send a pull request. If we get a pull request where an entire file is changed because of insignificant whitespace changes we cannot see what you have changed, and your contribution might get rejected.
Running cross-platform Cucumber features
All Cucumber implementations (cucumber-ruby, cucumber-jvm, cucumber-js) share a common set of Cucumber features to ensure all implementations support the same basic features. To run these you need to clone the cucumber-tck repo into your cucumber-jvm working copy:
git submodule update --init
Now you can run the cross-platform Cucumber features:
gem install bundler bundle install rake
Below are some common problems you might encounter while hacking on Cucumber-JVM - and solutions.
IntelliJ Idea fails to compile the generated I18n Java annotations
This can be solved by changing the Compiler settings:
Preferences -> Compiler -> Java Compiler:
- Use compiler:
Javac in-process (Java6+ only)
- Additional command line parameters:
-target 1.6 -source 1.6 -encoding UTF-8
This is a reminder to the developers:
First, make sure you have the proper keys set up - in your
~/.m2/settings.xml - for example:
<settings> <servers> <server> <id>cukes.info</id> <username>yourcukesinfouser</username> <privateKey>fullkeypath</privateKey> </server> <!-- See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide --> <server> <id>sonatype-nexus-snapshots</id> <username>yoursonatypeuser</username> <password>TOPSECRET</password> </server> <server> <id>sonatype-nexus-staging</id> <username>yoursonatypeuser</username> <password>TOPSECRET</password> </server> </servers> </settings>
Replace version numbers in:
- README.md (this file)
git commit -am "Release X.Y.Z"
Now release everything:
mvn release:clean mvn --batch-mode -P release-sign-artifacts release:prepare -DautoVersionSubmodules=true -DdevelopmentVersion=1.1.2-SNAPSHOT mvn -P release-sign-artifacts release:perform
Post release the API docs must be generated for each module and manually copied over to a working copy of the cucumber.github.com which must be a sibling of
cucumber-jvm (this repo):
After that's done, commit and push
Code coverage is collected mainly to identify code that can be deleted or needs to be tested better. To generate a report, run:
This technique to collect coverage for a multi-module Maven project is based on a blog post by Thomas Sundberg.