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
The smack-compression-jzlib subproject is obsolete since Java 7 de-
and inflate support was added with SMACK-389. Now it is time to remove
it.
Fixes SMACK-840.
This is a complete redesign of what was previously
XmppNioTcpConnection. The new architecture allows to extend an XMPP
client to server (c2s) connection with new transport bindings and
other extensions.
Introducing Smack's own XmlPullParser interface which tries to stay as
compatible as possible to XPP3. The interface is used to either wrap
StAX's XMLStreamReader if Smack is used on Java SE, and XPP3's
XmlPullParser if Smack is used on on Android.
Fixes SMACK-591.
Also introduce JUnit 5 and non-strict javadoc projects.
This commit adds the modules smack-omemo and smack-omemo-signal.
smack-omemo is licensed under the Apache license like the rest of the smack project.
smack-omemo-signal on the other hand is licensed under the GPLv3.
Due to the fact, that smack-omemo is not of much use without smack-omemo-signal,
the OMEMO feature can currently only be used by GPLv3 compatible software.
This may change in the future, when a more permissively licensed module becomes available.
Fixes SMACK-743.
This commit marks an important milestone with the addition of the
smack-android subproject. Smack is now able to run native on Android
without requiring any modifications, which makes the aSmack build
environment obsolete.
It was necessary to redesign the code for SASL authentication to achieve
this. Smack now comes with smack-sasl-provided for SASL implementations
that do not rely on additional APIs like javax for platforms where those
APIs are not available like Android.
instead of using the old baseName=smack appendix=project.name approach,
we are now going convention over configuration and renaming the
subprojects directories to the proper name.
Having a prefix is actually very helpful, because the resulting
libraries will be named like the subproject. And a core-4.0.0-rc1.jar is
not as explicit about what it actually *is* as a
smack-core-4.0.0-rc1.jar.
SMACK-265
The jingle subproject builds now. This doesn't change that the code is
outdated with regard to the specification and unmaintained for
years. But hopefully this is the first step to change that. :)
The integration tests have been moved into SourceSets of 'core' and
'extensions'.
