While markdown is easier to write, Smack's markdown documentation was
never tightly coupled with the source. For example, the markdown
documentation never provided links to the actual Java classes and
methods. This poses the risk that the documentation and the code
diverge over time. Furthermore, javadoc is constantly improving (for
example @snippet annotations) and I expect that one will be able to
write javadoc in markdown.
Fixes SMACK-928.
The UserTuneIntegrationTest, in rapid succession:
- add a listener for PEP-published usertune data
- publishes a usertune
- waits for a notification to arrive
Implicit to adding the listener is the publication of a change in
Pubsub notification filtering. This can involve a stanza handshake,
as CAPS is involved.
A race condition exists where the usertune data can be published
before the notification filter has been properly applied.
The changes in this commit add a synchronzation point that ensures
that the notification filter is in place, before the usertune data
is published.
Co-authored-by: Paul Schaub <vanitasvitae@fsfe.org>
Some roster-based tests depend on there not being any prior subscription state beteween entities. The utility method that
tries to guarantee that, acts on the state of the roster that's cached in memory, but acts on the one that's stored on the
server. This occasionally causes issues, as both representations might be different.
Stability is added in this commit by:
- refreshing the roster from the server prior to evaluating it
- ignoring an 'item-not-found' as returned by the server, when the code tries to remove that item.
If something goes wrong when destroying a MUC, we want to be notified
about it immediately, as further results of the integration test run
are unreliable anyway.
ExtensionElement is now a marker interface that requires all
implementation non-abstract classes to carry a static final QNAME
field (of type QName). This is verified by a new unit test.
Also FullyQualifiedElement is renamed to simply XmlElement. XmlElement
is used over ExtensionElement when implementing classes do not
statically know the qualified name of the XML elements they
represent. In general, XmlElement should be used sparingly, and every
XML element should be modeled by its own Java class (implementing
ExtensionElement).
The MAM integration test setup attepts to set MAM preferences (XEP-0441).
When a server does not support this XEP, the setup phase errors out, preventing
the tests from being executed.
There is no functional reason why tests shouldn't be run when XEP-0441 is not
supported: the tests can run against the default configuration of the MAM
service.
This commit ignores feature-not-implemented errors when MAM
preferences are set.
[Ignore only feature-not-implemented errors, log ignored errors)
Modified-by: Florian Schmaus <flo@geekplace.eu>
If we do not create the fromMarkers initialized with 'false' at the
start, then it may appear like all messages are received, because we
only check for false markers. But if there is not even the fromMarkers
array, then we do not see those 'false' markers.
This also lifts a bunch of logic from smack-websocket-okhttp into
smack-websocket. Furthermore, the following subprojects require now
Java 11:
- smack-integration-test
- smack-omemo-signal-integration-test
- smack-repl
- smack-websocket-java11
Related tracking issue: SMACK-835
This also means that smack-integration-test needs to declare a
dependency on Guava, which was previously available as transitive
dependency of 'reflections' 0.9.11.
This also resulted in a refactoring of the Providers and parsing
Exceptions. NumberFormatException and ParseException can now be thrown
directly, the wrapping in a SmackParsingException is down at a higher
layer, i.e. in AbstractProvider.
