You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the goals of the reference implementation is to maintain the number of dependencies as lower as possible. With that spirit, a modular approach has been followed, letting the users decide, depending on their workflows nature, which dependencies should be include.
49
+
One goal of the reference implementation is including the lowest number of dependencies possible. In that spirit, a modular approach has been used, letting the user decide which dependencies to include based on the nature of their workflow.
50
50
51
-
In practical terms, this means a separation between the core part and additional dependencies that should be explicitly included if your workflow is interacting with an external service that communicated using a particular technology supported by the specification (at this moment, just HTTP). The intention of this is to avoid adding dependencies that you do not need (for example, when gRPC call will be implemented, if we were adding the gRPC stack to the core dependencies, you won't be able to get rid of it even if none of your workflows use it)
51
+
In practical terms, this means establishing a separation between the core part and additional dependencies that should be explicitly included if your workflow is interacting with an external service using a particular technology supported by the specification (at this moment, just HTTP). The intention of this is to avoid adding dependencies that you do not need. For example, when gRPC call will be implemented, if we were adding the gRPC stack to the core dependencies, you won't be able to get rid of it even if none of your workflows use it.
52
52
53
53
#### Maven
54
54
@@ -72,8 +72,6 @@ And only if your workflow is using HTTP calls, you must add:
72
72
</dependency>
73
73
```
74
74
75
-
76
-
77
75
### Gradle projects:
78
76
79
77
You always need to add this dependency to your build.gradle `dependencies` section:
@@ -88,7 +86,6 @@ And only if your workflow is using HTTP calls, you must add:
The quick version is intended for impatient users who want to try something as soon as possible.
@@ -168,9 +165,9 @@ To execute a workflow, we first create a [WorkflowInstance](core/src/main/java/i
168
165
.thenAccept(node -> logger.info("Waiting instance completed with result {}", node));
169
166
```
170
167
171
-
The next line will be executed as soon as the workflow execution starts waiting for events to arrive, moment at which control is returned to the calling thread. Therefore, we can execute another workflow instance while the first one is waiting.
168
+
As soon as the workflow execution reach the point where it waits for events to arrive, control is returned to the calling thread. Therefore, we can execute another workflow instance while the first one is waiting.
172
169
173
-
We will send an event with a temperature that does not satisfy the criteria, so the listen instance will continue waiting. We use a regular Java ' Map ' to pass parameters to the workflow instance that sends the event. Note that since we want to wait till the event is published before executing the following line, we call `join` after `start`, telling the `CompletableFuture` to wait for workflow completion.
170
+
We will send an event with a temperature that does not satisfy the criteria, so the listen instance will continue waiting. We use a regular Java ' Map ' to pass parameters to the workflow instance that sends the event. Note that since we want to wait till the event is published, we call `join` after `start`, telling the `CompletableFuture` to wait for workflow completion.
0 commit comments