Initial release

.circleci/config.yml

@@ -0,0 +1,145 @@
+version: 2
+jobs:
+  build:
+    docker:
+      - image: circleci/openjdk:8u171-jdk-stretch
+
+    working_directory: ~/repo
+
+    environment:
+      TERM: dumb
+      JAVA_TOOL_OPTIONS: -Xmx2048m
+      GRADLE_OPTS: -Dorg.gradle.daemon=false -Dorg.gradle.workers.max=2
+      GRADLE_MAX_TEST_FORKS: 2
+
+    steps:
+      - checkout
+      - run:
+          name: Check submodule status
+          command: git submodule status | tee ~/submodule-status
+
+      - restore_cache:
+          name: Restoring cached submodules
+          keys:
+          - v1-submodules-{{ checksum "~/submodule-status" }}
+
+      - run:
+          name: Update submodules
+          command: git submodule update --init --recursive
+
+      - run:
+          name: Install Sodium Library
+          command: |
+            sudo sh -c "echo 'deb http://deb.debian.org/debian unstable main contrib non-free' > /etc/apt/sources.list"
+            sudo apt-get update
+            sudo apt-get install -y libsodium23
+
+      - restore_cache:
+          name: Restoring cached gradle dependencies
+          keys:
+          - v1-gradle-dir-{{ checksum "build.gradle" }}
+          - v1-gradle-dir-
+
+      - run:
+          name: Downloading dependencies
+          command: ./gradlew allDependencies checkLicenses
+
+      - run:
+          name: Compiling
+          command: ./gradlew spotlessCheck assemble
+
+      - run:
+          name: Collecting artifacts
+          command: |
+            mkdir -p ~/jars
+            find . -type f -regex ".*/build/libs/.*jar" -exec cp {} ~/jars/ \;
+          when: always
+
+      - store_artifacts:
+          name: Uploading artifacts
+          path: ~/jars
+          destination: jars
+          when: always
+
+      - run:
+          name: Running tests
+          command: ./gradlew --stacktrace test
+
+      - run:
+          name: Collecting test results
+          command: |
+            ./gradlew jacocoTestReport
+            mkdir -p ~/test-results/
+            find . -type f -regex ".*/build/test-results/.*xml" -exec cp {} ~/test-results/ \;
+          when: always
+
+      - store_test_results:
+          name: Uploading test results
+          path: ~/test-results
+          destination: tests
+          when: always
+
+      - run:
+          name: Collecting reports
+          command: |
+            mkdir -p ~/reports/license
+            (cd ./build/reports/license && tar c .) | (cd ~/reports/license && tar x)
+            find . -type d -regex ".*/build/reports/tests/test" | while read dir; do
+                  module=`echo $dir | sed -e 's/build\/reports\/tests\/test//'`
+                  mkdir -p ~/reports/test/"$module"
+                  (cd "$dir" && tar c .) | (cd ~/reports/test/"$module" && tar x)
+              done
+              find . -type d -regex ".*/build/reports/jacoco/test/html" | while read dir; do
+                  module=`echo $dir | sed -e 's/build\/reports\/jacoco\/test\/html//'`
+                  mkdir -p ~/reports/jacoco/"$module"
+                  (cd "$dir" && tar c .) | (cd ~/reports/jacoco/"$module" && tar x)
+              done
+          when: always
+
+      - store_artifacts:
+          name: Uploading reports
+          path: ~/reports
+          destination: reports
+
+      - run:
+          name: Building JavaDoc
+          command: ./gradlew :javadoc
+
+      - store_artifacts:
+          name: Uploading JavaDoc
+          path: build/docs/javadoc
+          destination: javadoc
+
+      - run:
+          name: Building Dokka docs
+          command: ./gradlew :dokka
+
+      - store_artifacts:
+          name: Uploading Dokka docs
+          path: build/docs/dokka
+          destination: dokka
+
+      - deploy:
+          name: Deploying snapshot to Bintray (master branch only)
+          command: |
+            if [ "${CIRCLE_BRANCH}" == "master" ]; then
+              echo "Start deployment"
+              ./gradlew deploy
+            else
+              echo "Start dry run deployment"
+              export BINTRAY_DRYRUN=true
+              ./gradlew deploy
+            fi
+
+      - save_cache:
+          name: Caching gradle dependencies
+          paths:
+          - .gradle
+          - ~/.gradle
+          key: v1-gradle-dir-{{ checksum "build.gradle" }}-{{ .Branch }}-{{ .BuildNum }}
+
+      - save_cache:
+          name: Caching submodules
+          paths:
+            - .git/modules
+          key: v1-submodules-{{ checksum "~/submodule-status" }}

.editorconfig

@@ -0,0 +1,5 @@
+[*.{kt,kts}]
+indent_size=2
+continuation_indent_size=2
+insert_final_newline=true
+max_line_length=120

.gitattributes

@@ -0,0 +1,3 @@
+* text eol=lf
+*.jar -text
+*.bat -text

.gitignore

@@ -0,0 +1,26 @@
+*.bak
+*.swp
+*.tmp
+*~.nib
+*.iml
+*.launch
+*.swp
+*.tokens
+.classpath
+.externalToolBuilders/
+.gradle/
+.idea/
+.loadpath
+.metadata
+.prefs
+.project
+.recommenders/
+.settings
+.springBeans
+.vertx
+bin/
+local.properties
+target/
+tmp/
+build/
+out/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "eth-reference-tests/src/test/resources/tests"]
+	path = eth-reference-tests/src/test/resources/tests
+	url = https://github.com/ethereum/tests.git

CONTRIBUTING.md

@@ -0,0 +1,61 @@
+# Contributing to Cava
+
+Welcome to the Cava repository! This document describes the procedure and guidelines for contributing to the Cava project. The subsequent sections encapsulate the criteria used to evaluate additions to, and modifications of, the existing codebase.
+
+## Contributor Workflow
+
+The codebase is maintained using the "*contributor workflow*" where everyone without exception contributes patch proposals using "*pull-requests*". This facilitates social contribution, easy testing and peer review.
+
+To contribute a patch, the workflow is as follows:
+
+* Fork repository
+* Create topic branch
+* Commit patch
+* Create pull-request, adhering to the coding conventions herein set forth
+
+In general a commit serves a single purpose and diffs should be easily comprehensible. For this reason do not mix any formatting fixes or code moves with actual code changes.
+
+## Style Guide
+
+`La mode se démode, le style jamais.`
+
+Guided by the immortal words of Gabrielle Bonheur, we strive to adhere strictly to best stylistic practices for each line of code in this software.
+
+At this stage one should expect comments and reviews from fellow contributors. You can add more commits to your pull request by committing them locally and pushing to your fork until you have satisfied all feedback. Before merging, you should aim to have a clean commit history where each commit identifies an specific change, or where all
+commits are squashed together.
+
+#### Stylistic
+
+The fundamental resource Cava contributors should familiarize themselves with is Oracle's [Code Conventions for the Java TM Programming Language](http://www.oracle.com/technetwork/java/codeconvtoc-136057.html), to establish a general programme on Java coding. Furthermore, all pull-requests should be formatted according to the (slightly modified) [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html), as it will be checked by our continuous integration architecture, and code that does not comply stylistically will fail to build.
+
+#### Architectural Best Practices
+
+Questions on architectural best practices will be guided by the principles set forth in [Effective Java](http://index-of.es/Java/Effective%20Java.pdf) by Joshua Bloch
+
+#### Clear Commit/PR Messages
+
+Commit messages should be verbose by default consisting of a short subject line (50 chars max), a blank line and detailed explanatory text as separate paragraph(s), unless the title alone is self-explanatory (such as "`Implement EXP EVM opcode`") in which case a single title line is sufficient. Commit messages should be helpful to people reading your code in the future, so explain the reasoning for your decisions. Further explanation on commit messages can be found [here](https://chris.beams.io/posts/git-commit/).
+
+#### Test coverage
+
+The test cases are sufficient enough to provide confidence in the code’s robustness, while avoiding redundant tests.
+
+#### Readability
+
+The code is easy to understand.
+
+#### Simplicity
+
+The code is not over-engineered, sufficient effort is made to minimize the cyclomatic complexity of the software.  
+
+#### Functional
+
+Insofar as is possible the code intuitively and expeditiously executes the designated task.
+
+#### Clean
+
+The code is free from glaring typos (*e.g. misspelled comments*), thinkos, or formatting issues (*e.g. incorrect indentation*).
+
+#### Appropriately Commented
+
+Ambiguous or unclear code segments are commented. The comments are written in complete sentences.