By not directly depending on Bouncycastle (BC), we avoid conflicts between
different bouncycastle versions. It is also part of the developers job
to take care that all required security primitives are available. If
they are provide by BC or some other security provider should not be
up to Smack to decide.
We now only add BC as test dependency to satisfy this requirement when
the unit tests are executed.
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.
Also add minidns-core as dependency to smack-core. This requires
increasing the minimum required Android SDK level to 9, as this is
what MiniDNS requires.
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.
on package layer instead of Declarative Service (DS) approach.
Restructuring and cleanup of initialization process to ensure that all
internal config files are found by the corresponding bundle
classloaders.
SMACK-343
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.
as there exists no longer a dependency from smack (now smack-core) to
smackx (now mostly smack-extensions). Therefore this approach is no
longer needed.
SMACK-343
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
