|
| 1 | +# Developer Guide |
| 2 | + |
| 3 | +This guide provides development workflows that are used to develop and maintain |
| 4 | +the import-export-udf-common-scala and the projects based on it. It is intended for those who wish to address |
| 5 | +the issues, merge a pull request, perform release or deep dive into the codebase |
| 6 | +of the project. |
| 7 | + |
| 8 | +## Contributing |
| 9 | + |
| 10 | +Contributions to the import-export-udf-common-scala projects are very welcome! |
| 11 | + |
| 12 | +Please feel free to report a bug, suggest an idea for a feature, or ask a |
| 13 | +question about the code. |
| 14 | + |
| 15 | +Please keep in mind that contributions are not only pull requests. They can be |
| 16 | +any helpful comment on issues, improving documentation, enhancing the build process |
| 17 | +and many other tasks. |
| 18 | + |
| 19 | +### Getting in Touch |
| 20 | + |
| 21 | +Please feel free to report a bug, suggest an idea for a feature, or ask a |
| 22 | +question about the code. |
| 23 | + |
| 24 | +You can create an issue using [Github issues][gh-issues] or follow a standard |
| 25 | +[fork and pull][fork-and-pull] process to contribute a code via [Github pull |
| 26 | +requests][gh-pulls]. |
| 27 | + |
| 28 | +If you do not know where to start, please have a look at [open |
| 29 | +issues][open-issues]. You can choose the ones that interest you the most. If you |
| 30 | +are new to the project, check out the issues labeled as |
| 31 | +[good-first-issue][first-issue]. |
| 32 | + |
| 33 | +### Submitting a Pull Request |
| 34 | + |
| 35 | +Once you have found an interesting feature or issue to contribute, you can |
| 36 | +follow the steps below to submit your patches. |
| 37 | + |
| 38 | +- Create a new feature branch, `git checkout -b "cool-new-feature"` |
| 39 | +- Code |
| 40 | +- Write tests for changes |
| 41 | +- Update documentation if needed |
| 42 | +- **Make sure everything is working**, run `./scripts/ci.sh` |
| 43 | +- If everything is okay, commit and push to your fork |
| 44 | +- [Submit a pull request][submit-pr] |
| 45 | +- Let us work together to get your changes reviewed |
| 46 | +- Merge into master or development branches |
| 47 | + |
| 48 | +If your commit fixes any particular issue, please specify it in your commit |
| 49 | +message as `Fixes issue [issue number]`. For example, `Fixes issue #29`. |
| 50 | + |
| 51 | +Some best practices when creating a pull request: |
| 52 | + |
| 53 | +- Rebase or update |
| 54 | +- Squash your commits |
| 55 | +- Reword your commits |
| 56 | +- Write clear commit messages |
| 57 | + |
| 58 | +## Development Environment |
| 59 | + |
| 60 | +You need to have Java version 11 or above installed on your development |
| 61 | +machine. |
| 62 | + |
| 63 | +Additionally, we assume you have some experience doing Scala development. If you |
| 64 | +have any questions in general or about the development process, please feel free |
| 65 | +to get in touch. |
| 66 | + |
| 67 | +## Building the Project |
| 68 | + |
| 69 | +First clone a local copy of the repository: |
| 70 | + |
| 71 | +```bash |
| 72 | +git clone https://github.com/exasol/import-export-udf-common-scala.git |
| 73 | +``` |
| 74 | + |
| 75 | +Then run `./sbtx`, and run any of these commands: |
| 76 | + |
| 77 | +- `clean` : cleans previously compiled outputs; to start clean again. |
| 78 | +- `compile` : compiles the source files. |
| 79 | +- `test:compile`: compiles the unit test files. |
| 80 | +- `it:compile` : compiles the integration test files. |
| 81 | +- `test` : run all the unit tests. |
| 82 | +- `it:test` : run all the integration tests. |
| 83 | +- `doc` : generate the api documentation. |
| 84 | + |
| 85 | +You can also run several commands combined together: |
| 86 | + |
| 87 | +``` |
| 88 | +;clean;test;it:test |
| 89 | +``` |
| 90 | + |
| 91 | +Additionally, you can run `testOnly filename` or `it:testOnly filename` commands |
| 92 | +to only run single file tests. |
| 93 | + |
| 94 | +### Running E2E Build Script |
| 95 | + |
| 96 | +Inside the `scripts/` folder, you will find the `ci.sh` bash file, that runs |
| 97 | +end-to-end build process. This file is intended to be run in continuous |
| 98 | +integration (CI) environment. For the continuous integration we use the [Travis |
| 99 | +CI](https://travis-ci.com/). |
| 100 | + |
| 101 | +Please run this file to make sure that everything is working before committing |
| 102 | +code or submitting a pull request. |
| 103 | + |
| 104 | +```bash |
| 105 | +./scripts/ci.sh |
| 106 | +``` |
| 107 | + |
| 108 | +Additionally, ensure that the `ci.sh` scripts work with different versions of |
| 109 | +the Scala programming language. You can check that with the following command: |
| 110 | + |
| 111 | +```bash |
| 112 | +TRAVIS_SCALA_VERSION=2.11.12 ./scripts/ci.sh |
| 113 | +``` |
| 114 | + |
| 115 | +## Checking the Test Coverage |
| 116 | + |
| 117 | +The `ci.sh` script also creates the code coverage reports. They are located in |
| 118 | +the target path, `target/scala-<SCALA.VERSION>/scoverage-report/`. |
| 119 | + |
| 120 | +You can open the `index.html` file, it should show the code coverage reports per |
| 121 | +file. |
| 122 | + |
| 123 | + |
| 124 | + |
| 125 | +You can also generate the coverage reports using the `sbt` command line, by |
| 126 | +running: |
| 127 | + |
| 128 | +```bash |
| 129 | +;clean;coverage;test;it:test;coverageReport |
| 130 | +``` |
| 131 | + |
| 132 | +## Checking the Dependency Updates |
| 133 | + |
| 134 | +It is important to keep the dependencies up to date. |
| 135 | + |
| 136 | +You can check out if any of dependencies or plugins have new versions, by |
| 137 | +running the following commands. |
| 138 | + |
| 139 | +Check if any plugins have new versions: |
| 140 | + |
| 141 | +```bash |
| 142 | +pluginUpdates |
| 143 | +``` |
| 144 | + |
| 145 | +Check if any dependencies have new versions: |
| 146 | + |
| 147 | +```bash |
| 148 | +dependencyUpdates |
| 149 | +``` |
| 150 | + |
| 151 | +### Dependency Tree and Artifact Eviction |
| 152 | + |
| 153 | +You can check the dependency tree by running the command below: |
| 154 | + |
| 155 | +```bash |
| 156 | +dependencyTree |
| 157 | +``` |
| 158 | + |
| 159 | +Additionally, it is also good practice to check the evicted artifacts, and maybe |
| 160 | +to exclude them explicitly when declaring the library dependencies. In order to |
| 161 | +check the evicted artifacts, run: |
| 162 | + |
| 163 | +```bash |
| 164 | +evicted |
| 165 | +``` |
| 166 | + |
| 167 | +## Editor Setups |
| 168 | + |
| 169 | +We try to keep the codebase code editor agnostic. But we tested that it works |
| 170 | +with IntelliJ. |
| 171 | + |
| 172 | +Any setups required for editors are out of scope. However, this can change when |
| 173 | +we get contributors who use those code editors :) |
| 174 | + |
| 175 | +## Conclusion |
| 176 | + |
| 177 | +This guide is expected to change and evolve with the changes to the project. |
| 178 | +Any pull requests to keep this document updated are very much appreciated! |
| 179 | + |
| 180 | +[gh-issues]: https://github.com/exasol/import-export-udf-common-scala/issues |
| 181 | +[gh-pulls]: https://github.com/exasol/import-export-udf-common-scala/pulls |
| 182 | +[fork-and-pull]: https://help.github.com/articles/using-pull-requests/ |
| 183 | +[gh-releases]: https://github.com/exasol/import-export-udf-common-scala/releases |
| 184 | +[submit-pr]: https://github.com/exasol/import-export-udf-common-scala/compare |
| 185 | +[open-issues]: https://github.com/exasol/import-export-udf-common-scala/issues |
| 186 | +[first-issue]: https://github.com/exasol/import-export-udf-common-scala/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 |
| 187 | +[import-export-udf]: https://docs.exasol.com/loading_data/user_defined_import_export_using_udfs.htm |
0 commit comments