Thanks for donating your time to developing coderadar! This is the most valuable contribution you can make.
This guide gives an overview of coderadar and some development guidelines to make it easier for new contributors to get up and running. If you have any questions, feel free to get in touch.
Major components are documented via a README file in the folder of the component. The following list links to those READMEs:
- coderadar-app: Contains the coderadar application and has a dependency on every other module.
- coderadar-core: Contains the core logic of coderadar. Has a dependency on coderadar-plugin-api.
- coderadar-graph: Contains database logic and connects to Neo4j.
- coderadar-plugin-api: API classes for creating analyzers.
- coderadar-plugins: Analyzer plugins that are by default contained in the coderadar server.
- coderadar-vcs: Contains logic for working with git repositories.
- coderadar-rest: Contains all REST-endpoints.
- coderadar-dependency-map: Contains logic for calculating dependency maps.
- coderadar-test: Contains integration tests.
- coderadar-ui: Contains the coderadar UI.
Any kind of contribution is welcome as a pull request. If you are unsure on how to fork a repository and then create a pull request from your fork, please read this blog post for a quick guide.
You can pick any issue from the issue tracker. We try to document all feature ideas, tasks and bugs as issues in the tracker. Issues marked with the tag "up-for-grabs" are especially documented so that new contributors should get an idea of what is to do. You might want to start with one of those tasks. You can just as well pick any other task, though. If you have any questions, get in touch.
If you have an idea, submit it to the issue tracker for discussion. I will let you know my thoughts. If you want to develop your idea yourself, you can do so and submit a pull request.
Below are some hints on conventions used in this project. If you are unsure about any, just get in touch. During a pull request review, we will also check these conventions. Fear not, the worst thing that may happen if you do not follow them is that we might propose some changes to a pull request you submitted.
For java code style, the gradle plugin "spotless" has been included in the build to enforce the
Google Java Code style. Builds will fail if
the code does not comply to the style guide. To apply the style guide simply call
gradlew spotlessApply. Only after applying the style guide should you push your changes.
Hint: in order for automatic style guide enforcement to work, you have to disable automatic code formatting on check-in in your IDE!
Please keep documentation up-to-date when changing the code. Documentation is made up of the following elements:
- Documentation of the REST API. This documentation is made with AsciiDoctor and Spring RestDocs. Example requests and responses are generated automatically from the integration tests covering the REST controllers. The documentation files are here.
- README.md files in the folders of all main components
- Javadoc: please provide sensible javadoc of at least public API
- This contribution guide: this guide is not carved in stone, so when things change, change this guide.
Simply run gradlew build.
- install Neo4j
- copy the file
coderadar-app/src/main/resources/application.properties.templateinto a file namedapplication.propertiesin the same folder and edit the configuration parameters in that file for your local environment and database - run
gradle build bootRunfrom the project directory - coderadar will be accessible on
localhost:8080by default - alternatively, if you have Docker installed, running
./run.shorrun.batwill start coderadar and Neo4j in docker images.
- start coderadar
- install a REST client like DHC
- refer to the REST API documentation to see what calls you can make and submit them using your REST client