Merge pull request #27 from HotSushi/main_fix_dev

Add docs/development/* back

docs/development/client-code-generation.md

@@ -0,0 +1,41 @@
+## Workflow
+# Produce OpenApi Spec for the server
+To enable a server to produce OpenApi spec, just include the following code block in its build.gradle:
+```
+plugin {
+  id 'com.github.johnrengelman.processes' version '0.5.0'
+  id 'org.springdoc.openapi-gradle-plugin' version '1.3.3'
+  id 'openhouse.service-specgen-convention'
+}
+```
+This will create the spec file in `<Root>/build/<Service>/specs/`.
+
+# Generate client for the server
+Each generated client should have its corresponding module. These modules are placed in `:client`, for example
+`:client:hts`.  Just add a build.gradle with following code block:
+```
+plugins {
+  id 'java'
+  id 'openhouse.client-codegen-convention'
+  id 'openhouse.springboot-conventions'
+}
+
+ext {
+  codeGenForService = ":services:housetables"
+}
+
+apply from: "${project(':client:common').file("codegen.build.gradle")}"
+```
+Note: the service should be enabled to produce spec file.
+
+## FAQ
+### The service controller was changed on my local build, but the generated client doesn't reflect it. WTD?
+OpenApi gradle plugin doesn't reproduce the spec file when code change happens. Because of this, the spec doesn't contain
+the latest Api details. We can re-trigger the spec generation by doing a `:clean` on the server module.
+
+Client codegen will be automatically triggered if it detects a spec file change.
+
+Steps involved for `:hts` would be:
+```
+./gradlew :service:housetables:clean :client:hts:build 
+```

docs/development/container-images.md

@@ -0,0 +1,24 @@
+# Container Images
+
+- [Container Images](#container-images)
+  - [Build container images locally](#build-and-run-container-images-locally)
+  - [Prepare MP to produce container images](#prepare-mp-to-produce-container-images)
+  - [Monitoring Metrics]()
+
+## Build and Run container images locally
+
+Dockerfile for each of the services are made available. Below are the example commands for Tables service
+defined by tables-service.Dockerfile.
+
+```  
+    # Build Container Image for Tables Service
+    docker build [--build-arg JAR_FILE=$JAR_FILE | --tag $REPOSITORY:$TAG] --file tables-service.Dockerfile .
+    
+    # Run the Container Image for Tables Services
+    docker run [--env OPENHOUSE_CLUSTER_CONFIG_PATH=$[FILE_PATH]] [--interactive --tty | --detach] -p [$HOST_IP]$HOST_PORT:8080 $REPOSITORY:$TAG
+```
+
+## Monitoring Metrics
+
+Services can be configured to report metrics for operational monitoring using prometheus. OpenHouse uses prometheus
+as the time-series database for storing metrics.

docs/development/intellij-setup.md

@@ -0,0 +1,24 @@
+# Build OpenHouse
+## Prerequisite
+- Java 1.8 or above
+- Scala 2.12 or above
+
+## Steps 
+Simply run `./gradlew clean build`.
+
+
+# Using IDE
+## IntelliJ
+There are a few subprojects, like `:client:tableclient` that contains no code before build and include generated
+source as part of source files during build runtime. There are also classes imports generated source as libraries.
+To ensure they are properly indexed by IDE, you need to:
+- Run a full build after fresh repository checkout.
+- Open the OpenHouse project from the root `build.gradle` file in the repo.
+
+### Fixing missing classes errors
+Intellij doesn't work nicely with shadow plugin, this is a known issue tracked here: [IntelliJ IDEA unable to resolve classes of project dependency shadow jar #264](https://github.com/johnrengelman/shadow/issues/264)
+
+Modules such as `:integrations:spark:openhouse-spark-itest` `:integrations:java:openhouse-java-itest` face this issue.
+
+To fix this issue please follow instructions as follows: [define-library](https://www.jetbrains.com/help/idea/library.html#define-library)
+![](ide-setup-for-shadow-jars.gif)