mirror of
https://github.com/corda/corda.git
synced 2024-12-29 17:28:56 +00:00
67 lines
4.3 KiB
ReStructuredText
67 lines
4.3 KiB
ReStructuredText
CLI vs IDE
|
|
==========
|
|
|
|
We have tried to make every demo, example, tutorial and sample to be both usuable via the command line and also the IntelliJ IDE.
|
|
Most developers will find writing, editing and debugging code more easily done via tools such as an IDE, but when code needs
|
|
to be deployed to run as nodes, control must be done via the command line - no organisations allow their systems to be running via
|
|
a developer environment.
|
|
|
|
IDE - IntelliJ
|
|
--------------
|
|
|
|
IntelliJ (the preferred IDE in R3) integrates well with gradle (our chosed build, deploy and CLI tool). IntelliJ understands gradle
|
|
tasks and dependencies, automatically loading them in the background when a project is first loaded 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 <https://www.jetbrains.com/idea/documentation/>`_.
|
|
|
|
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 preceeding 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 / cloaning 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 hierachical and therefore tasks in child directories can be run using a colon seperator - ie if you want to run
|
|
the sample attachment-demo ``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 makes 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. |