This is an automated email from the ASF dual-hosted git repository.

agoncharuk pushed a commit to branch ignite-14272
in repository https://gitbox.apache.org/repos/asf/ignite-3.git

commit a16573fe2d0ca341d4b9df8af5f76bb916eeddc8
Author: Alexey Goncharuk <alexey.goncha...@gmail.com>
AuthorDate: Wed Mar 10 15:39:30 2021 +0300

    IGNITE-14272 DEVNOTES.md moved to proper location, added draft modules 
structure
---
 DEVNOTES.md                                        | 55 +++++++++++++++++++++-
 modules/DEVNOTES.md                                | 47 ------------------
 modules/README.md                                  | 19 ++++++++
 .../configuration-annotation-processor/README.md   |  5 ++
 modules/network/README.md                          | 18 +++++++
 5 files changed, 95 insertions(+), 49 deletions(-)

diff --git a/DEVNOTES.md b/DEVNOTES.md
index 5575f29..0185e9b 100644
--- a/DEVNOTES.md
+++ b/DEVNOTES.md
@@ -1,13 +1,64 @@
-## Local Build
+# Setting up and building
+## Prerequisites
+ * Java 11 SDK
+ * Maven 3.6.0+ (for building)
+ 
+## Building Ignite
+Ignite follows standard guidelines for multi-module maven projects, so it can 
be easily built using the following 
+command from the project root directory (you can disable the tests when 
building using `-DskipTests`):
 
     mvn clean install [-DskipTests]
 
 Upon completion, you will find the CLI tool under `modules/cli/target` 
directory.
 Use `ignite` on Linux and MacOS, or `ignite.exe` on Windows. 
 
-## License Headers Check
+### Running tests
+To run unit tests only, use the following command:
 
+    mvn test
+
+Before running integration tests, make sure to build the project using the 
``package`` target.
+
+To run unit + integration tests, use the following command:
+
+    mvn integration-test
+
+To run integration tests only, use the following command:
+
+    mvn integration-test -Dskip.surefire.tests=true
+    
+### Sanity check targets
+Use the following commands to run generic sanity checks before submitting a PR.
+
+RAT license validation:
+    
     mvn validate
+    
+Checkstyle code validation:
+
+    mvn checkstyle:checkstyle:aggregate
+
+PMD static code analysis
+
+    mvn compile pmd:check 
+
+
+## Setting up IntelliJ Idea project
+You can quickly import Ignite project to your IDE using the root `pom.xml` 
file. In IntelliJ, choose `Open Project` 
+from the `Quick Start` box or choose `Open...` from the `File` menu and select 
the root `pom.xml` file.
+
+After opening the project in IntelliJ, double check that the Java SDK is 
properly configured for the project:
+
+ * Open the `File` menu and select `Project Structure...`
+ * In the SDKs section, ensure that a 1.11 JDK is selected (create one if none 
exist)
+ * In the `Project` section, make sure the project language level is set to 
11.0 as Ignite makes use of several Java 11 
+ language features
+ 
+Ignite uses machine code generation for some of it's modules. To generate 
necessary production code, build the project
+using maven (see Building Ignite).
+
+## Code structure
+High-level modules structure and detailed modules description can be found in 
the [modules readme](modules/README.md).
 
 ## Release candidate verification
 
diff --git a/modules/DEVNOTES.md b/modules/DEVNOTES.md
deleted file mode 100644
index 8e6d2a1..0000000
--- a/modules/DEVNOTES.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Setting up and building
-## Prerequisites
- * Java 11 SDK
- * Maven 3.6.0+ (for building)
- 
-## Building Ignite
-Ignite follows standard guidelines for multi-module maven projects, so it can 
be easily built using the following 
-command from the project root directory:
-```commandline
-mvn clean install
-```
-You can disable the tests when building using the following command:
-```commandline
-mvn clean install -DskipTests
-```
-
-### Running tests
-To run unit tests only, use the following command:
-```commandline
-mvn test
-```
-
-Before running integration tests, make sure to build the project using the 
``package`` target.
-
-To run unit + integration tests, use the following command:
-```commandline
-mvn integration-test
-```
-
-To run integration tests only, use the following command:
-```commandline
-mvn integration-test -Dskip.surefire.tests=true
-``` 
-
-## Setting up IntelliJ Idea project
-You can quickly import Ignite project to your IDE using the root `pom.xml` 
file. In IntelliJ, choose `Open Project` 
-from the `Quick Start` box or choose `Open...` from the `File` menu and select 
the root `pom.xml` file.
-
-After opening the project in IntelliJ, double check that the Java SDK is 
properly configured for the project:
-
- * Open the `File` menu and select `Project Structure...`
- * In the SDKs section, ensure that a 1.11 JDK is selected (create one if none 
exist)
- * In the `Project` section, make sure the project language level is set to 
11.0 as Ignite makes use of several Java 11 
- language features
- 
-Ignite uses machine code generation for some of it's modules. To generate 
necessary production code, build the project
-using maven (see Building Ignite).
diff --git a/modules/README.md b/modules/README.md
new file mode 100644
index 0000000..6b3f13b
--- /dev/null
+++ b/modules/README.md
@@ -0,0 +1,19 @@
+# Apache Ignite modules
+We try to make Apache Ignite reasonably modular in order to simplify unit and 
integration testing.
+Each module provides an exposed API which should be used by external modules. 
Not exposed APIs must not be used
+by external modules. At the time of writing we do not use Java JIGSAW modules 
system, but it is likely that we will
+at some point, which will help us to control the exported API contract.
+
+We prohibit cyclic dependencies between modules in order to simplify JIGSAW 
migration in the future.
+
+## Modules list
+
+Module Name | Description
+----------- | -----------
+[network](network/README.md)|Networking module: group membership and message 
passing
+[configuration-annotation-processor](configuration-annotation-processor/README.md)|Tooling
 for generating Ignite configuration model classes from configuration schema 
definition
+[configuration](configuration/README.md)|Ignite configuration classes and 
configuration management framework
+[runner](runner/README.md)|Ignite server node runner. The module that wires up 
the Ignite components and handles node lifecycle
+[rest](rest/README.md)|REST management endpoint bindings and command handlers
+[cli-common](cli-common/README.md)|Shared interfaces definitions for pluggable 
CLI
+[cli](cli/README.md)|Ignite CLI implementation
diff --git a/modules/configuration-annotation-processor/README.md 
b/modules/configuration-annotation-processor/README.md
new file mode 100644
index 0000000..b459187
--- /dev/null
+++ b/modules/configuration-annotation-processor/README.md
@@ -0,0 +1,5 @@
+# Configuration annotation processor
+This module provides a build extension that is used by Ignite to automatically 
generate configuration POJO classes
+from configuration schema definition.
+
+*TODO* describe how annotation processor works.
\ No newline at end of file
diff --git a/modules/network/README.md b/modules/network/README.md
new file mode 100644
index 0000000..faddaab
--- /dev/null
+++ b/modules/network/README.md
@@ -0,0 +1,18 @@
+# Ignite networking module
+This module provides an abstraction and default implementation of networking 
layer for Ignite. The module provides
+two major functions:
+ 
+* Discovery and group membership. The networking layer interface provides 
weakly-consistent discovery and group 
+membership service which uses the Scalecube implementation of the SWIM gossip 
protocol. The default implementation 
+requires a set of seed IP addresses to provided on start.
+* Messaging service. The networking layer provides several useful abstractions 
that can be used for sending and 
+receiving messages across nodes in the cluster. Several delivery guarantee 
options are available:
+  * Weak mode provides a 'shoot and forget' style of sending a message. These 
messages are not tracked for delivery and 
+  may be dropped by either sender or receiver. This is the preferred way of 
communication between nodes as such messages 
+  do not incur any risks of OOME or other resource shortage. For example, Raft 
server messages should be sent via weak 
+  mode because all Raft messages can be arbitrarily dropped.
+  * Patient mode attempts to deliver a message until either it is 
acknowledged, or we received a notification that a
+  target cluster member left the cluster. Internally, the networking module 
preserves a queue which orders scheduled
+  messages and persistently attempts to establish a connection and deliver 
scheduled messages in that particular order.
+  Messages sent via patient mode cannot be arbitrarily dropped and are kept in 
a memory buffer until either they are 
+  delivered or a destination node is reported as failed. 

Reply via email to