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.
This allows to avoid redundant XML namespaces within IQs, like for
example here:
<iq xmlns='jabber:client' id='EKP8I-1' type='set'>
<jingle xmlns='urn:xmpp:jingle:1' action='content-accept' sid='MySession'>
<content xmlns='urn:xmpp:jingle:1' creator='initiator' name='Hello world'>
</content>
</jingle>
</iq>
Fixes SMACK-917
Reported-by: Jonathan Lennox
XmlPullParser.getName() only returns a result if the current parser
event is START_ELEMENT or END_ELEMENT. If this is not the case, then
the method may throw (if StAX is used).
XmlPullParser.getName() only returns a result if the current parser
event is START_ELEMENT or END_ELEMENT. If this is not the case, then
the method may throw (if StAX is used).
Refactored using
find . -type f -name "*.java" |\
xargs sed -i -E |\
's/\.createStanzaCollectorAndSend\((\w+)\)\.nextResultOrThrow\(\);/.sendIqRequestAndWaitForResponse(\1);/'
and some manual refactoring.
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).
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.
Apply builder pattern to form fields and replace getVariable() with
getFieldName(). Refer to the field name as "field name" instead of
"variable" everyone, just as XEP-0004 does.
Improve the high-level form API: introduce FilledForm and FillableForm
which perform stronger validation and consistency checks.
Also add FormFieldRegistry to enable processing of 'submit' forms
where the form field types are omitted.
Smack also now does omit the form field type declaration on 'submit'
type forms, as it is allowed by XEP-0004.
Returning a generic would allow for
List<ExtensionElement> list = stanza.getExtension("foo", "bar");
to compile (Note the we are calling getExtension(), not
getExtension*s*()).
Users are encouraged to use the type safe getExtension(Class<? extends
ExtensionElement) variant instead.
Fixes SMACK-825.
- Reduce the amount of types that are subtypes of NamedElement. See
javadoc of NamedElement for rationale.
- Work more with XmlEnvironment in XmlStringBuilder.
- Some minor changes to XmlStringBuilder API.
This is needed for javadocAll since otherwhise there will be
smack-core/src/main/java/org/jivesoftware/smack/package-info.java:21:
warning: a package-info.java file has already been seen for
package org.jivesoftware.smack
warnings.
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.
At some point IQChildElementXmlStringBuilder was modified to add the
closing quote around the namespace. this was not reflected in these
element extensions
Guus der Kinderen
Florian Schmaus
Ingo Bauersachs
Paul Schaub
dave-stanley