The list of CorDapps jars is no longer passed in via the cmd line but is now expected to be placed in the bootstrapped directory.
Ended up being a bit of a refactor to cater for unit testing, and also tidied up the bootstrapper docs.
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](7a077e76f0 (diff-0948c125db93a22263eb81eaf3161c17R65))
did not make it into the 3.1 release, so from an API-stability perspective,
this change can be applied without affecting our commitment to a
backwards compatible API..
* Added new 'eventHorizonDays' configuration item.
* Added custom authenticator to provide ARTIFACTORY credentials upon resolving protected internal URL.
* Re-pointed functional test scenarios to point to Enterprise master.
* Enterprise corda network scenarios to use NetworkBootstrapper tool (instead of Doorman/NMS) since decision made by Product Management to split out Doorman/NMS from Enterprise.
* Configuration parameter changed to 'runMigration' since DP3.
* Fixed problem with logger upon startup.
* General improvements and additions to setup and execution scripts (eg. SIMM valuation demo now consists of 3 separate jars)
* Updates to decouple from Network Services.
* Download all JARs from artifactory for a given published distribution.
* Add TODOs for Doorman/NMS rework.
* Addressing TL PR review comments.
* Additional instructions for setting up the environment and running QA tests.
* Fixed repository URL references.
* Sprinkled new gradle dust to make both IntelliJ and TC (gradle) compilation happy.
* Fix compilation problem once and for all + ignore the RPCProxyWebServiceTest smoke test.
* Compendium of minor changes and improvements:
- build fat behave-jar so can run scenarios from shell scripts (from TC)
- additional run script to execute basic scenarios (for TC)
- default staging path shortened to "corda" (removed deps)
- toned down logging (info -> debug)
- fixed all compiler warnings
- fixed couple of bugs in startup checking steps
- base scenarios use variables declared using Examples parameterization
* Added missing braces
* Changes to address PR feedback.
* Mark underlying Cucumber libraries for future de-coupling.
* Better cert path validation exception message for PartyAndCertificate.verify (#2976)
* Corda Behave extensions for CTS (#2968)
* Updated to Corda 3.0, added support for PostgreSQL, added STAGING_ROOT environment variable, incorporating Watch improvements (Maks), Steps Provider interface for auto-scanning of 3rd party steps providers, re-implemented StepBlocks, new ScenarioRunner executable tool, additional Steps definitions (Vault, issue/transfer cash, cordapps), other minor bug fixes and logging improvements.
* Updates incorporating PR review feedback.
* Reverted back to original - will re-test in ENT.
* Removed all SQL Server code (to be included in ENT only)
* Minor updates following second PR review.
* Fixed broken scenario tests.
* Final fix for PostgreSQL scenario test.
* Updated to Corda 3.0, added support for PostgreSQL, added STAGING_ROOT environment variable, incorporating Watch improvements (Maks), Steps Provider interface for auto-scanning of 3rd party steps providers, re-implemented StepBlocks, new ScenarioRunner executable tool, additional Steps definitions (Vault, issue/transfer cash, cordapps), other minor bug fixes and logging improvements.
* Updates incorporating PR review feedback.
* Reverted back to original - will re-test in ENT.
* Removed all SQL Server code (to be included in ENT only)
* Minor updates following second PR review.
* Fixed broken scenario tests.
* Final fix for PostgreSQL scenario test.
