Nightly Distribution of the master branch

Build: #1844 was successful Changes by Florian Schmaus <flo@geekplace.eu>

Stages & jobs

  1. Default Stage

  2. Deploy

Build result summary

Details

Completed
Queue duration
7 minutes
Duration
11 minutes
Labels
None
Revision
89ef46525ea38e565e623234e907b701ab342e56
Total tests
830
Successful since
#1831 ()

Tests

Code commits

Author Commit Message Commit date
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> 89ef46525ea38e565e623234e907b701ab342e56 Merge branch '4.4'
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> fc7fc10c6967926c29df8aceea3ea0079c3356b3 m [pubsub] Allow for character data before <item/>'s payload
Fixes SMACK-918.
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> e39adff40fd3feae41e793994f870112f57cf131 m [muc] Only notify() about processed self-presence once
Since notify() is a rather expensive operation, we should only invoke
it once. Especially since some servers include 110 in all self
presences, not just the initially reflected one on MUC join.
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> d1273532ce01625bf7f73885144b55ad830546fb m [muc] Correctly processes self-presences
The change in 52a49769f9a8 ("[muc] Check for self-presence first in
presence listener") caused all self-presences (MUC user status 110) to
be ignored in the further processing chain eventually invoking
checkRoleModifications() and checkAffiliationModifications(). However,
some servers (e.g., ejabberd) include 110 not only in the initial
presence but in all following, and we ant to process these.

Fixes SMACK-918

Fixes: 52a49769f9a825a8c0252efcad0d96635fb257a6
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> 10a2687ff19722f4076c28227957b71418868aad [sinttest] Allow the selection of individual test *methods*

Jira issues

IssueDescriptionStatus
Unknown Issue TypeSMACK-918Could not obtain issue details from Jira