powered by Jive Software

Introducing myself - looking for mentor


I’m currently working on my diploma thesis at the Freie Universität Berlin, Department of Computer Science. The focus of the thesis is to improve the Smack library which is used in the project Saros, an Eclipse plugin for distributed party programming.

So far I’ve created patches for the SOCKS5 bytestream feature (SMACK-297, SMACK-298, SMACK-299, SMACK-300, SMACK-301, SMACK-302, SMACK-303) and for registering the RosterListener before login (SMACK-156).

Currently I’m working on a patch to improve the message packet parser (see SMACK-243 and “Bug: XmlPullParserException”).

After that I plan to concentrate on the Jingle API by fixing the issues SMACK-283 and SMACK-267 and implementing Jingle IBB and Jingle SOCKS5 transport methods. In order to do that the IBB API should be extracted from the current file-transfer API analogue to the SOCKS5 API. Then it should be possible to provide the SOCKS5 API and IBB API with some sort of PacketFactory so that the same code could be used in the context of Jingle.

Another goal of the thesis is to help (re)activating the Smack developer community by making it more transparent for dedicated developers how to contribute code and how to join the community. Therefor I wrote a guideline document for Smack contributors. Feel free to discuss and improve it.

I would like Guenther Niess to be my mentor (if he likes) but maybe there is someone else who is more into the file-transfer and Jingle API.

If anyone likes to help me with the Jingle stuff, please tell me. Maybe we can work together on this.

Best regards,

Not a coder myself, so no technical advices Just wanted to said that it’s great to have you on our team. By improving Smack you will also improve Spark, which i’m using.

Hi Henning,

Thanks for your input so far! Let me know if things work out with Guenther - if not, I’ll try to make some time available for mentoring. I’m currently swamped with work, so if Guenther or someone else is available for mentoring, that would be better/faster.

I’ve already started to review your patches and commented on SMACK-298 my first thoughts. Yes it’s true filetransfer and jingle is a new subject for me, but I like to learn and review good code. Because I’m also relatively new maybe someone want to join me in reviewing. I think if more people have a look on the code, we will maybe improve the code quality.

Henning used mockito and powermock for his unit tests. I don’t used mock objects before but it seems to be a powerful and easy method to write readable unit tests. I think all tests can be writen without mock but with more code. So I would like to hear other opinions if we should introduce these libraries for unit tests.


here is a summary of what I’ve done so far and what the status is:


Improve Socks5 bytestream

SMACK-297, SMACK-298, SMACK-299, SMACK-300, SMACK-301, SMACK-302, SMACK-303, SMACK-137, SMACK-239, SMACK-169
50% reviewed

Register RosterListener Before Login

not reviewed

Improve Delay Information Parser

not reviewed

Improve Message Parser Robustness and Message Body I18N

SMACK-307, SMACK-207, SMACK-252
not reviewed

Add Support for Localized Message Subjects

not reviewed

Improved In-Band Bytestream

not reviewed

Binary XMPP XEP-0239

not laughed

Sadly there is not much progress in reviewing the patches. Günther Nieß told me he is quite busy at the moment but will continue reviewing in the next couple of weeks. So I’d like to ask Guus and Robin if they can review one of the smaller patches.

I would also like to publish the guideline document … just to show that there is still some activity in the project.

Also the “Becoming a Contributing Member” document should be published too to encourage more people to contribute to Smack.

And we should also think about making a new official release of the Smack 3.1.1 version. Is there any plan for that?

Best regards,


Hi Guenther,

“So I would like to hear other opinions if we should introduce these libraries [mockito and powermock] for unit tests.”

Openfire has only a few JUnit tests and we should not stop Henning writing or contributing JUnit tests because we don’t know the supporting or helping tools. It would be similar to say that one must use “vi” instead of Eclipse to write Java code.

Better JUnit tests which need 3rd party libraries than little or no JUnit tests.

==> I would add those libraries.



it’s great that the guideline document is published now, although this was not the way it was supposed to be published. I hoped that all or at least a majority of the core members would agree to publish it and that the document would be placed in the Smack community board. The contributors group is fine too but maybe we should consinder placing a document in the Smack community board linking to all the guidelines of the contributors group just to make them easier to find.

I also wanted to ask if there is any progress in reviewing my patches? I think after 4 month they should be either declined or commited to the SVN.

It also seems that there is almost no activity for Smack anymore. So if you all don’t have time to review the patches or commit them to the SVN it would be great if I could get SVN write access to commit the patches. (Also it gets more and more difficult to create patches that don’t conflict with my other patches). If I would get SVN commit rights I would take responsibility for the FileTransfer and Bytestreams features in Smack and try to fix any newly introduced bugs as fast as possible. (Like Robin does for the PubSub feature)

Additionally I think we must do something to move things along in the Smack project. One idea is to create some kind of roadmap for the next versions of Smack so that existing contributors have a goal and new smack contributors could be assigned to implement smaller features of that roadmap to become familiar with the Smack code. I’ve prepared a first draft:


Smack 3.1.1

  • finish XEP-0124 BOSH and merge it to trunk
  • including patches for IBB, SOCKS5, Message Parser, Delay Information Parser, Message Subjects and RosterListener to trunk
  • move static methods from class SyncPacketSend to Connection class and use it in the existing code where applicable to cleanup code

Smack 3.1.2

  • apply recommended packet structure (feature.packet, feature.provider) to existing features
  • move non-XNPP standard features in separate source folder / jar file (SharedGroupManager, smackx.workgroup, BridgedTransportManager)
  • refactor/replace and update XEP-0166 Jingle implementation to current specification
  • add logger for classes in smack and smackx packages and replace all e.printStacktrace()
  • implement XEP-0260 Jingle SOCKS5 Bytestreams Transport Method
  • implement XEP-0261 Jingle In-Band Bytestreams Transport Method
  • implement XEP-0234 Jingle File Transfer
  • write documentation for Jingle

Smack 3.1.3

  • implement XEP-0191 Simple Communications Blocking
  • implement XEP-0084 User Avatar
  • implement XEP-0199 XMPP Ping
  • implement XEP-0224 Attention
  • implement XEP-0231 Bits of Binary
  • implement XEP-0264 File Transfer Thumbnails
  • implement XEP-0279 Server IP Check

Pleas tell me if you think this is a good idea and what other points could be added.

Best regards,


Henning, you’re right, you should have commit access. We’ll get that sorted first (see the other thread in which is discussed). After that, you’re free to make mistakes as much as you can (as others have put it).

As for Smack - I’m not that heavily involved - and I prefer to keep it that way. Currently, Matt Tucker is still the designated project lead, but I think we can safely assume that he is no longer, effectively. I’m perfectly happy for someone else (you?) to take over that role. I would actually welcome it, as it will give a new impulse.

What’s the take of others on this?

It sounds good to me. I was asked by Matt if I would be interested in helping to push out a new release of Smack after I added the pubsub functionality. I was willing to help out at that time but it was never mentioned again and I got too busy with other things. I am still willing to help out, and creating a roadmap would be a good start. Does someone have access to the appropriate build machines to actually generate a new build and tag it approriately? I am guessing as Guus mentioned there is probably some lack of ownership there.

Actually, even the roadmap should be a second priority. The first should be to actually create a 3.2 release based on the current code base and any currently logged Jira tasks that would be considered gating. I say 3.2 since I think the pubsub API alone should justify the 3.2 over a 3.1.1 as it is not just a couple of minor bug fixes. It is getting a fair bit of usage that I can tell and it seems a shame that everyone has to build the source to use it. It would also be an exercise in developing a build process to create such a new release. This should be much simpler than the OpenFire release since it is just a library, with no executable setup required for different environments.

As for the development process: that will have the sime issues as Openfire is currently having. We’ll need to wait for the new servers to become available.