* Add LegalProseReference annotation
* Migrate code from autogenerated javascript to TypeScript source
* Add instructions to rebuild the web resources
* Make installWeb more reproducible
Update to use LedgerTransaction api
Push query output logic onto BaseTransaction and update usages where possible
Migrate a few more uses
Address some PR comments
Address some PR comments
Fixup after rebase
Refactor generator calls to use a visitor type pattern to avoid duplicating
the class writer boiler plate. Each generate<Type> call passes its own
function to the wrapping class that writes the boiler plate and then
calls back into the type specific methods before returning bacl to
finlaise the class writer and load it into the class loader
Remove unkotlinesq spaces
Currently the carpenter only generates concreate classes, add the
ability to also synthesise interfaces and have those interfaces used by
other gnerated classes
Switch to using AbstractParty as the standard identifier for parties in
states, so that full parties can be used during construction of
transactions and anonymised parties when the transaction is being added
to the ledger.
Move AbstractParty, AnonymousParty and Party into a new net.corda.core.identity package,
as they're not really cryptography tools, and in preparation for further code coming in
for identity.
Optimize imports on many files to clean up the resulting refactor.
Change the legal name of parties to be an X500 name. This ensures that we aren't converting between
common names and X500 names in various places, eliminating substantial scope for error in the conversion
process. As a result, all node names must now be full X500 names, which has impact on most configurations.
* Make CompositeKey implement PublicKey
The initial implementation of composite keys as their own distinct class separate from PublicKey
means that the keys cannot be used on standard classes such as Certificate. This work is a beginning
to modifying CompositeKey to being a PublicKey implementation, although significant further work
is required to integrate this properly with the standard Java APIs, especially around verifying
signatures using the new key type.
* First stage of making CompositeKey implement PublicKey interface. Revert to using PublicKey everywhere we expect a key.
* Move algorithm and format into companion object (#432)
Move algorithm and format into companion object so that they can be referenced from other
classes (i.e. the upcoming signature class).
* Add simple invariants to construction of CompositeKey.
Builder emits CompositeKeys in simplified normalised form. Forbid keys with single child node, force ordering on children and forbid duplicates on the same level. It's not full semantical normalisation.
* Make constructor of CompositeKey private, move NodeWeight inside the class.
Add utility function for Kryo deserialization to read list with length constraints.