Release 15.0 (#59)

Bump version to 15.0-SNAPSHOT

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Remove deprecated methods

Removes the deprecated members of MALContextFactory, ConnectionConsumer,
SingleConnectionDetails, HelperMisc, SplitBinaryDecoder, SplitBinaryEncoder
and MALSender. Nothing in the repository called any of them.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Replace MOErrorException with the dedicated exception classes

The MOErrorException(UInteger, Object) constructor is deprecated and sets
the error name to “????”. The 59 sites that passed a constant error number
now construct the generated exception class for that error, which carries
the declared name. The remaining sites take the error number at runtime,
either decoded from the wire or deliberately undefined, and are unchanged.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Remove the deprecated MOErrorException constructor

The constructor named every error it created “????”. The decode paths that
relied on it now name the error UNRESOLVED, and ErrorBody logs the error
number it could not resolve.
The testbed handlers raised error numbers that predate the generated error
classes: 999, which no area declares, and 0, which the remaining constructor
rejects outright. Both are replaced by InternalException, already used by the
default branch of the same switches.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Remove the deprecated HelperAttributes conversion methods

The four methods delegated to Attribute, which declares them with the same
signatures. The remaining call sites, all in TestHelperAttributes, now call
Attribute directly.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Import the MAL structures on demand in MALMessageHeader

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Format a timestamp on Time and FineTime

The two classes formatted themselves through HelperTime. They now hold the
formatting, and DATE_PATTERN joins ONE_MILLION on Attribute, so neither
structure depends on helpertools any longer.
The deprecated HelperTime.time2readableString methods keep the null check
their signature declares and defer the rest, leaving one copy of the
formatting.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Remove the deprecated HelperTime.time2readableString methods

The call sites now format through Time.toReadableString() and
FineTime.toReadableString().
The two tests for the null argument are dropped rather than converted: they
assert a contract of the static methods, and an instance method cannot be
reached through a null reference to raise it.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Remove the old api-generator modules

generator-interfaces, generator-java and generator-docs are deleted, which
is the v15.0 cut-over of DESIGN.md section 10.9.
The Maven plugin calls api-generator-lib directly. targetLanguages selects
one of the library’s generators by short name, and parent/pom.xml names
Java outright, so NewJavaGenerator, the esa.stubgen.generator property and
the new-generator profile are removed. The plugin drops packageBindings,
generateStructures, generateCOM, extraProperties and xsdRefDirectory, which
had nothing behind them any longer. forceGeneration is kept, since it
overrides the plugin’s own up-to-date check rather than the generator.
mo-navigator generates Java and documents through the library. The library
writes a document as a directory of parts; Generation zips each into a
.docx, as the old generator did. The MOSDL editor is unchanged and now
declares jaxb-api itself.
jaxb-runtime and jaxb2-maven-plugin leave the parent, as only the old
modules’ xjc executions used them.
The 950 Java files generated for apis/* match the golden baseline. The only
document differences are the MC v001 diagrams already recorded in
intended-differences.txt. The baseline is not re-captured here.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Generate the INVOKE and PROGRESS acknowledgement classes

The Java generator wrote a class holding a multi-field answer only for
the RESPONSE of a REQUEST. The acknowledgement of an INVOKE or a
PROGRESS with more than one field is the same case, and the consumer
stub already names the class, so test-api-mal no longer compiled.
An object reference spelled into the name, as ObjectRef(Auto), was
encoded as the abstract type it names. The generator it replaced
encodes that spelling as a concrete ObjectRef, while the objectRef=”true”
form keeps following the type it refers to; the shipped APIs depend on
the latter, so the distinction is kept.
The golden tree missed both: it covered only apis/*, and compared only
the files the generator wrote. test-api-mal and test-api-com join the
baseline, captured with the 14.2 generator, golden.sh builds and
captures them, and a baseline file that is not generated now counts as
a difference.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Remove MALInteractionException from the provider operations

A handler method now throws the errors its operation declares, as the
generated exception classes, and MALException for a failure of the
provider itself, which the MAL returns as an internal error. An error
the operation does not declare can no longer be raised.
The generated INVOKE and PROGRESS interaction classes declare only
MALException on their send methods: the MAL interaction declares a
MALInteractionException on each send, which is carried as the cause.
The consumer side, the publishers and the MAL interfaces are unchanged.
The providers are migrated. The alert service throws the UNKNOWN its
operations declare instead of wrapping it. In the testbeds:

MALPrototype createObject and createObjectFromFields declare
DATA_ERROR, which the data type test expects of them.
The error test operations do nothing, as their specification states:
the transport raises the error before the provider is invoked, and a
provider raising it itself masked a failure to do so.
The fast provider raises its declared TEST_ERROR, and the errors the
test procedures trigger are MALExceptions.

The golden baseline is re-captured for the changed provider classes.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Send the SUBMIT acknowledgement of Action execute once

execute sent the acknowledgement itself, and the skeleton sends it
again when the handler returns, so every accepted request was
acknowledged twice and the consumer dropped the second one as an
unknown transaction. Returning now accepts the request.
The execution events are published on another interaction, which the
MAL does not order against the acknowledgement, so sending it early
did not order them either.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Throw typed errors from the consumer stubs

A consumer stub method throws the errors its operation declares, each as
its own class, then MALStandardError, the new parent of the MAL error
classes, and MALException. MALStandardError.relayOrWrap ends each catch:
it throws a MAL standard error as its own class and wraps any other
error, which the operation does not declare, in a MALException.
Asynchronous and continue calls throw MALStandardError and MALException
only. The adapters are unchanged; the error they receive is typed.
Error numbers are not unique across areas, so an error is resolved
against the errors its operation declares, then those of the service’s
area, then the MAL standard errors. ServiceInfo.generateMOError takes the
operation number, and ServiceInfo.resolveError applies it. mal-impl
resolves every error a consumer receives through ResolvedErrorBody, so
the result does not depend on the transport; the unresolved-error log
drops to FINE. A MALTransmitErrorException becomes the cause of the
error it carries, which keeps the header of the failed message
reachable.
The consumers in this repository are migrated. Code that inspected error
numbers catches the error classes instead, and code that logs any error
catches MOErrorException. The MC testbed’s table-driven error tests still
compare numbers. The golden baseline is re-captured for the stubs,
ServiceInfo classes, area helpers and MAL error classes.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Make MOErrorException abstract

Every error is an instance of its own class: the one generated for each
error a specification defines, or UnresolvedError for a number that
resolves to none of them. Transports decode an error as UnresolvedError,
and resolution tests for that class instead of comparing the class of the
error with MOErrorException. The name UNRESOLVED, repeated in three error
bodies, is held by UnresolvedError.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Build received errors in the MAL, and rename UnresolvedError to UndefinedError

A transport no longer returns an error that is not yet resolved. The
error body gives the error number and the extra information, and the
MAL builds the error from them with ServiceInfo.errorOf, which replaces
resolveError: the class a specification defines for the number, or an
UndefinedError where none defines it. UndefinedError, renamed from
UnresolvedError, names only that outcome.
ResolvedErrorBody.errorOf builds the error for every error message a
consumer receives, and logs an undefined error at FINE. A body that is
itself an error was created where the message was, and is that error,
so its cause is kept. The generic ErrorBody and the fast test transport
resolve through the message header; the in-process test transport
returns the error it was given.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Add the Version 15.0 release notes

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Date the Version 15.0 release notes

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Bump version to 15.0 for release

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Co-authored-by: Claude Opus 5 noreply@anthropic.com