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.
- De-duplicate code by moving it into AbstractXMPPConnection
- Introduce TopLevelStreamElement as superclass for all XMPP stream elements.
- Add SynchronizationPoint, ParserUtils
- Add ParserUtils
Fixes SMACK-333 and SMACK-521
The idea is that xml-roundtrip should *never* be expected from a
XmlPullParser. So what we need is a method that parses the content of an
element without relying on getText() returning text if on START_TAG or
END_TAG. This is already done by PubSubs ItemProvider.
Also add PacketParserUtils.parseElement() which will return the current
element as String and use this method in PubSub's ItemProvider.
by using XmlStringBuilder. Fixes SMACK-577
Also extend LazyStringBuilder with a cache. And extend XmlStringBuilder
with some more convenience methods.
Move the ELEMENT and NAMESPACE definition from Form to DataForm, where
it belongs.
Move some duplicate code from XMPP(TCP|BOSH)Connection to
PacketParserUtils. Remove TestUtils as the method now part of Smack's
public API in PacketParserUtils.
Most importantly, rename reload() method of persistent cache to
"DiscoverInfo lookup(String nodeVer)" and lazily load the data from the
persistent cache to the memory cache.
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
