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.
instead of an EntityFullJid, because according to XEP-0045 § 7.8.1.:
"The <room@service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant
JID of the inviter …"
instead of throwing XmlPullParserException, IOException and
SmackException.
Add a guard to AbstractXMPPConnection.processPacket() to always re-throw
RuntimeExceptions.
- Made jid of type BareJid
- Made it implement TypedCloneable
- Made it implement Serializable
- Made it immutable
Also update its parsing code. And add some convenience methods to
ParserUtils.
this is the first stop towards fixing "SMACK-65: parsing should look for
depth", by providing the initial parsing depth to the provider. Some
methods (.e.g parseMessage) now use the depth as abort condition,
instead of a unclean String equals check.
parseIQ() and parseExtension() where both renamed to parse.
This also restricts the Exceptions thrown by the parse method, to just
XmlPullParserException, IOException and SmackException (not really a big
victory, but nevertheless a slight improvement).
StreamFeatureProvider is now gone, we simply use PacketExtensionProvider
for stream features.
Removes a ton of duplicate code, mostly related to MUCItem being
duplicated in MUCOwner and MUCAdmin, but also some other duplicate code.
Make MUC code use XmlStringBuilder.
Add ELEMENT and NAMESPACE constants to the appropriate places. Also add
"static <MUCPacketExtension> getFrom(Packet)" methods.
Make some MUC classes implement Element.
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
Ingo Bauersachs
Florian Schmaus
Paul Schaub