| commit | d64206cf0e42ba8bed7b873bed430c3229546fc3 | [log] [tgz] |
|---|---|---|
| author | Thorsten Schöning <6223655+ams-tschoening@users.noreply.github.com> | Fri Sep 04 02:50:28 2020 +0200 |
| committer | GitHub <noreply@github.com> | Thu Sep 03 20:50:28 2020 -0400 |
| tree | 19728919db7968001e21b2a83b84237a13d45e00 | |
| parent | 31446277b02220df577f1e945add2bb1f4c18a84 [diff] |
Changed some docs and model dependencies for tests etc. using MVN. (#35) * Remove reference to build tools that are no longer supported * Remove the Java style dependencies page * Add a paragraph on the building page on running unit tests * Add a systems to the 'covered by team' section * Add a systems to the 'covered by team' section * Incorporate changes from review * Incorporate changes from review * Keep the dependencies, but try to make more use of them regarding necessary binaries to test with. This reverts commit b42df2f2a6f8b1eafc6ad36b222c2a0edf8a7244. * A PoC of adding depenencies like GREP etc. using Maven and public repos. * Added a PoC to model necessary bins for tests using a local MVN-repo. * Couldn't find a reference that ZIP is necessary for tests. I don't have it in my PATH-variable. * Had an additional look at what is really necessary for tests and couldn't find a reference to GREP anymore. Additionally, GZIP seems to be required at runtime in "gzcompressaction.cpp" as well, not only in tests or better, not additionally in tests. So I've refactored the modeled dependencies to take that into account. * Put dependencies in markdown format * Replacing MVN-based dependencies in favour of a customly maintained markdown-table with those. MVN might be removed in the not too far future anyway and the approach using a local repo seems pretty complicated as well. The markdown document as well easily provides support for arbitrary describing text beyond a table. * Added a hint that CMAKE does things automatically only. Co-authored-by: Stephen Webb <stephen.webb@sabreautonomous.com.au> Co-authored-by: Stephen Webb <swebb2066@gmail.com> Co-authored-by: Robert Middleton <robert.middleton@rm5248.com>
Issues are maintained in the Apache JIRA by default, so before posting pull requests, please have a look there if an associated issue with your problem/feature/... exists already. If not, it‘s generally OK to directly create pull requests IF code is already available, but please be somewhat verbose: Provide some background information about what actual problem the PR solves, why this needs to be solved etc. Don’t just provide commits about the fact that you changed something.
If any discussion is needed before actually having any code, simply create a ticket in JIRA or send a message to the corresponding mailing list. Thanks!