-
- -
-

CLI vs IDE

-

We have tried to make every demo, example, tutorial and sample usable via both the command line and the IntelliJ IDE. -Most developers will find writing, editing and debugging code more easy with tools such as an IDE. But when a production node -is deployed, it will be controlled via the command line - no organisation allows their systems to be running via -a developer environment.

-
-

IDE - IntelliJ

-

IntelliJ (R3’s preferred IDE) integrates well with gradle (our chosen build, deployment and CLI tool). IntelliJ understands gradle -tasks and dependencies, automatically loading them in the background when a project is first opened or the gradle -project changes. Occasionally, however, you may need to refresh the gradle project manually - but this is hinted to you -by the IDE. It’s a good idea to do this before carrying on with other work (and in fact you may find it is essential to pick -up new libraries, etc.).

-

There are some great resources about how to get started using IntelliJ. As opposed to trying to repeat them here, we advise -you to go to the IntelliJ docs here.

-
-
-

Command Line

-
-

Windows vs Mac / Unix

-

Due to the nature of their respective command interfaces, gradle is typically ran in windows with the command gradle.bat -(or gradlew.bat if using the wrapper) and in Mac / Unix environments it is ran via ./gradlew. For brevity, the -simple windows syntax gradle is used for the majority of the documentation.

-

As well as including the most significant run and build configurations in the IDE, we also provide gradle tasks to build, install -and run significant parts of Corda demos and tools. Gradle is highly extensible and we use it for downloading required resources, -building components, installing those built components into shared areas, configuring the scripts that run nodes, starting -up demonstration API calls amongst other things. It is exceptionally good at deriving dependency maps and therefore performing -the preceding tasks required in order to do the requested task. However, when confusing build errors manifest, then sometimes -a gradle clean may be required in order to clear out any build areas that have an inconsistent state. The total build time -from downloading / cloning the repo to a complete build should be only a few minutes, obviously slightly longer if the -unit tests are run.

-
-
-

Frequently Used Gradle Tasks

-

Note that the list of tasks can be ran for any gradle project can be displayed by running the task tasks. Also, note that -gradle is hierarchical and therefore tasks in child directories can be run using a colon separator. For example, if you want to run -the sample attachment demo run configuration runSender, you would use the command gradle samples:attachment-demo:runSender

-

The most frequent gradle tasks you will probably be running are build and install. The build command also executes the -unit tests as well. If you want to build without this level of verification, then use the assemble command - but we do -not recommend this. After running build, the install tasks copies over the built jars into the local maven repository -which will then make these available for either the sample code or use with the CorDapp template.

-
-
-
-

Debugging

-

Tasks and processes that are run directly via the IDE (including via the usage of the driver DSL) can be remotely debugged. -We do not have java debugging currently enabled in the runnodes scripts generated by a process we refer to as ‘cordformation’ -but we will be implementing that shortly.

-
-

Via the IDE

-

To debug: From the IDE, configure the debug connectivity option by the “Edit Configurations” and choosing “+” and then “Remote”. -The debug port start at 5005 and increments for each additional node that starts, the order given by the list in the main -driver configuration (which is primarily listed in the main function of Main.kt for each sample. Look for the string -Listening for transport dt_socket at address:5xxx in the log output to determine the exact port for that node. If the log -messages are mixed from several nodes to the same console, then (as earlier stated), the port numbers increment in the order -they are listed in the driver DSL configuration.

-
-
-
- - -
-