* Upgrade gradle wrapper to Gradle 5.0
* Upgrade to use locally deployed version of Capsule plugin (using Gradle 5.0)
* Upgrade to use Corda Gradle Plugins 5.x (inclusive of Gradle 5.0 compatibility fixes)
* Fix compile-time problems resolving log4j packages.
* Update to use Artifactory deployed version of Capsule plugin (using Gradle 5.0)
* Upgrade to use Gradle 4.2.1 (excluding default memory setting change: command line client now starts with 64MB of heap instead of 1GB.)
* Added explicit compile-time dependency on 'de.jensd:fontawesomefx-commons:8.13' (compile-time error in tools:explorer without)
* Update "wrapper" gradleVersion to 5.4.1
* Update Capsule plugin version label to reference R3 forked build.
* Commit all gradle upgrade changes following: ./gradlew wrapper --gradle-version 5.4.1
* Increase maximum heap memory for Test tasks to 1GB, and upgrade build-scan plugin to 2.2.1.
* Increase Test tasks' maximum memory to 1.5GB - what could go wrong?
* Up maxHeapSize to 2g for gradle test runner (global setting).
* Added explicit compile-time dependency on 'de.jensd:fontawesomefx-commons:8.13' (compile-time error in tools:demobench without)
* Added forkEvery for node Unit tests.
* Up :node test task 'forkEvery' to 10.
* TC test execution tuning (:core, :node => forkEvery 10, default JVM heap size)
* TC test execution tuning (bump JVM heap size up to 1g for :node)
* TC test execution tuning (bump JVM heap size up to 1.5g for :node)
* TC test execution tuning (re-instate global JVM heap size of 1Gb)
* TC test execution tuning (re-instate JVM heap size of 2Gb for :node)
* Update Corda Gradle plugins to 5.0.0
* Updated plugin resolution order + renamed artifactory URL to use "software.r3.com"
* Reorder plugin resolution such that mavenlocal() is always queried first.
This allows a different signed version of the same CorDapp to be automatically trusted.
This reverts "[CORDA-2575] Allow users to whitelist attachments by public key config (#5035)"
The Signature Constraint documentation in `api-contract-constraints`
was very limited and referred to the design doc for most information.
Information was extracted from the design doc and added to the main
documentation.
If a single whitelisted constraint is being used by input states and the version of the cordapp changes + is signed, then the constraint will transition to a signature constraint.
When a `UnexpectedFlowEndException` or a `FlowException` is received the
peer that the exception was thrown from will be added to the stacktrace.
This is due to it being easier to see and a field that developers
are much less likely to override.
A nullable field `peer` has been added to `FlowException` and
`UnexpectedFlowEndException`. This is read later on (when peer info
is not available) to append the peer info to the stacktrace.
* CORDA-2817 Revert CORDA-2162 but modify Cash move to allow multiple move commands and thus multiple generateSpends in the same transaction.
* CORDA-2817 Remove API changes and internalise into Cash.
* Tests for custom registry restrictions
* ENT-3121 restrict custom serialisation
* Remove redundant code
* Only count declared annotations
* Check annotation on superclasses, remove annotation from ByteArray
* Forbid custom serialization of primitive types
* Remove @CordaSerializable from another class that is always handled by custom serialisation
* Add log warnings to aid diagnosis of custom serialization issues
* Remove another annotation
* Remove another annotation
* Remove another annotation
* Remove another annotation
* Fixup api-current
* Fixup api-current
* KDocs on exceptions
In Corda 4, FinalityFlow was updated to become an initiated flow, in order to ensure a node does not have to accept any signed transaction it receives without being able to check it first. The old behaviour of FinalityFlow was gated behind a targetPlatformVersion check, to prevent apps targeting V4 from using the old behaviour.
This is problematic for a few reasons. For an app wishing to be backwards compatible with a version running on V3, this forces the app to set targetPlatformVersion = 3, even if the app is thoroughly tested against V4. This goes against the purpose of the targetPlatformVersion. Another consequence is that an app remains pinned to targetPlatformVersion = 3 until it is sure that there are no other apps running at a lower version in the network, which would prevent newer versions of the app from taking advantage of features gated behind targetPlatformVersion checks. (Note that the restriction only prevents a new version of the app from initiating FinalityFlow with the old version - the old version is able to initiate a FinalityFlow and the new version will handle it, assuming the app has been written correctly.)
This fix removes the targetPlatformVersion check from FinalityFlow, and also provides a few documentation updates to clarify what level of testing would be expected to set a targetPlatformVersion.
* CORDA-2694: Prevent Node Explorer from crashing should it receive unknown transaction objects.
Also ensure that LazyMappedList can only handle TransactionDeserialisationExceptions.
* CORDA-2694: Add unit tests for eager LazyMappedList behaviour.
* CORDA-2694: Hide LazyMappedList from the client:jfx module.
* CORDA-2694: Create an unknown transaction state that has the correct notary.
* CORDA-2688 - Add Serialization Context option for no carpenting
Can be used by the attachment class loader - Serialization Framework
will still consume all Exceptions and throw a NotSerializableException
* Fix tests
