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).
Those were broken since 9e797c1b17 as they
always used the basic PubSub namespace, i.e. without a fragment. Which
resulted in e.g. delete requests look like
<iq to="pubsub.ec-xmpp" id="2GAeW-75" type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<delete node="2e92d38c-9e90-47f6-8e26-330d25ebe96b"/>
</pubsub>
</iq>
when the namespace should be in fact
http://jabber.org/protocol/pubsub#owner
This is actually only part one, i.e. with this commit if the user adds a
PacketExtension to an IQ it will be included in IQ.toXml(). Which was
previously only the case if the IQ subclass explicitly included packet
extensions.
The second part of the change is to change the IQ provider, so that
packet extensions are automatically parsed.
Cases where PacketExtensions are used for Message and IQ are slightly
changed. The IQ sublcass now only has a field with this
PacketExtension (see for example
bytestreams.ibb.packet.DataPacketExtension).
Also changed hoxt API: Removed unnecessary indirection and made the
API more Smack idiomatic.
This also marks the starting point for extending the PubSub API to allow
additional packet extensions to be added to the request. This is for
example useful if one wants to limit the result with "Result Set
Management (XEP-59)".
Fixes SMACK-580.
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