to keep the order in which the elements are added.
Some XEPs define a Schema using 'xs:sequence' (see for example XEP-60 §
17.1), so the order the PacketExtensions are added should be the same
they are transformed to a XML String.
Those where never correctly implemented and are not really used. If you
want to compare Packets, compare their toXML() result.
N.B. that we keep hashCode/equals for Message.(Subject|Body) because
those are correct and are in-use ('bodies' and 'subjects' are Sets in
Message).
allowing O(1) lookups for PacketExtensions
The one EntityCapsManagerTest becomes obsolete with this change, as
duplicate extension elements (RFC 6120 § 8.4) are now no longer possible
after the stanza has been parsed (they still may be received on the
wire, but only the last duplicate will be added).
- 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
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
2014-04-28 19:44:14 +02:00
Renamed from core/src/main/java/org/jivesoftware/smack/packet/Packet.java (Browse further)
Florian Schmaus