<liclass="toctree-l1"><aclass="reference internal"href="tutorial-cordapp.html#running-the-cordapp-template">Running the CorDapp template</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="tutorial-cordapp.html#interacting-with-the-cordapp-template">Interacting with the CorDapp template</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="tutorial-cordapp.html#extending-the-cordapp-template">Extending the CorDapp template</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="oracles.html#implementing-an-oracle-with-continuously-varying-data">Implementing an oracle with continuously varying data</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="oracles.html#using-an-oracle">Using an oracle</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="setting-up-a-corda-network.html">Introduction - What is a corda network?</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="setting-up-a-corda-network.html#setting-up-your-own-network">Setting up your own network</a></li>
<h1>CLI vs IDE<aclass="headerlink"href="#cli-vs-ide"title="Permalink to this headline">¶</a></h1>
<p>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.</p>
<divclass="section"id="ide-intellij">
<h2>IDE - IntelliJ<aclass="headerlink"href="#ide-intellij"title="Permalink to this headline">¶</a></h2>
<p>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).</p>
<p>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 <aclass="reference external"href="https://www.jetbrains.com/idea/documentation/">IntelliJ docs here</a>.</p>
</div>
<divclass="section"id="command-line">
<h2>Command Line<aclass="headerlink"href="#command-line"title="Permalink to this headline">¶</a></h2>
<divclass="section"id="windows-vs-mac-unix">
<h3>Windows vs Mac / Unix<aclass="headerlink"href="#windows-vs-mac-unix"title="Permalink to this headline">¶</a></h3>
<p>Due to the nature of their respective command interfaces, gradle is typically ran in windows with the command <codeclass="docutils literal"><spanclass="pre">gradle.bat</span></code>
(or <codeclass="docutils literal"><spanclass="pre">gradlew.bat</span></code> if using the wrapper) and in Mac / Unix environments it is ran via <codeclass="docutils literal"><spanclass="pre">./gradlew</span></code>. For brevity, the
simple windows syntax <codeclass="docutils literal"><spanclass="pre">gradle</span></code> is used for the majority of the documentation.</p>
<p>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 <codeclass="docutils literal"><spanclass="pre">gradle</span><spanclass="pre">clean</span></code> 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
<h3>Frequently Used Gradle Tasks<aclass="headerlink"href="#frequently-used-gradle-tasks"title="Permalink to this headline">¶</a></h3>
<p>Note that the list of tasks can be ran for any gradle project can be displayed by running the task <codeclass="docutils literal"><spanclass="pre">tasks</span></code>. 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 <codeclass="docutils literal"><spanclass="pre">runSender</span></code> you would use the command <codeclass="docutils literal"><spanclass="pre">gradle</span><spanclass="pre">samples:attachment-demo:runSender</span></code></p>
<p>The most frequent gradle tasks you will probably be running are <codeclass="docutils literal"><spanclass="pre">build</span></code> and <codeclass="docutils literal"><spanclass="pre">install</span></code>. The <codeclass="docutils literal"><spanclass="pre">build</span></code> command also executes the
unit tests as well. If you want to build without this level of verification, then use the <codeclass="docutils literal"><spanclass="pre">assemble</span></code> command - but we do
not recommend this. After running build, the <codeclass="docutils literal"><spanclass="pre">install</span></code> 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.</p>
</div>
</div>
<divclass="section"id="debugging">
<h2>Debugging<aclass="headerlink"href="#debugging"title="Permalink to this headline">¶</a></h2>
<p>Tasks and processes that are run directly via the IDE (including via the usage of the <codeclass="docutils literal"><spanclass="pre">driver</span></code> DSL) can be remotely debugged.
We do not have java debugging currently enabled in the <codeclass="docutils literal"><spanclass="pre">runnodes</span></code> scripts generated by a process we refer to as ‘cordformation’
but we will be implementing that shortly.</p>
<divclass="section"id="via-the-ide">
<h3>Via the IDE<aclass="headerlink"href="#via-the-ide"title="Permalink to this headline">¶</a></h3>
<p>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 <codeclass="docutils literal"><spanclass="pre">main</span></code> function of <codeclass="docutils literal"><spanclass="pre">Main.kt</span></code> for each sample. Look for the string
<codeclass="docutils literal"><spanclass="pre">Listening</span><spanclass="pre">for</span><spanclass="pre">transport</span><spanclass="pre">dt_socket</span><spanclass="pre">at</span><spanclass="pre">address:5xxx</span></code> 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.</p>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
