Skip navigation
All Places > Ignite Realtime Blog > Author: rcollier

Ignite Realtime Blog

7 Posts authored by: rcollier Champion

Stepping Down as Lead

Posted by rcollier Champion Feb 2, 2014

It is with a heavy heart that I am stepping down as the project lead for Smack. 


I am happy to have managed to push out 6 releases in the last 3 years, but even from the start I always had issues finding the time to dedicate to this project.  Things have never really improved on that front.  Three young children and some unexpected illnesses in my family haven't exactly made for a lot of free time over the last couple of years. 


I have been thinking about this for awhile actually, but it has only been this year that some other eager contributors have come along with a lot of ideas and motivation for the project. So that makes for a good time to step aside and let those with time and dedication move the project forward.


I still plan on contributing when and if I can, but it will probably be less code and more helping others in the forums.  It takes much shorter blocks of time.


So, I wish the best of luck to Flow, who will be taking over my role as project lead.

Smack 3.4.0 is released

Posted by rcollier Champion Feb 2, 2014

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.4.0).  It is now available for download.  This release has a number of noteworthy changes.

  • Deployment structure - Changes reflect the idea of only keeping code that matches specifications that have gone at least as far as the Draft state in the smack or smackx jars.
    • Workgroups - This has been pulled out of the main jars and placed on it's own due to the fact that the spec it is based on hasn't reached the Draft status of the XEP process.  It was in fact moved to the Deferred state in 2005, and is not likely to ever move forward.
    • Experimental - New artifact to hold code that has not reached the Draft status of the XEP process.  It currently contains the new contribution for XEP-0280 - Message Carbons.  Due to the expectation that the specifications that this code is base on will be in a state of flux until being moved forward to a Draft state, this jar will have it's own versioning scheme.  Users should be aware that this code is apt to have API changes and such outside what can be expected of changes to the major version of Smack.  It may be more volatile to major changes and should be used with caution. Code deemed experimental will be 'promoted' once the specification has reached the Draft state.
  • Logging - Smack now uses Java util logging.  Prior to this release, what little logging was done consisted of dumping to the system console via System.out/err calls and the infamous printStackTrace calls.  Although it is not the most popular of logging libraries, it does not create any external dependencies and can be used in conjunction with either Log4j or Slf4j.
  • Configuration
    • Provider Management - Fixed the long standing issue (SMACK-286) of not being able to change how and where providers are loaded from.  The loading of providers from a specific file location has been pulled out of the ProviderManager.  The manager is now only responsible for managing the providers, not loading them as well.  The API has been augmented to allow for users to provide any means they wish to load providers.  A file based one which loads the current file format is provided, so any existing files can be easily added.  This can be utilized via the API or a VM argument.  The documentation has been updated to reflect these changes, please read for more details.
    • Initialization - System initialization can now be accomplished programmatically via additions to the SmackConfiguration API or by using the new a VM argument.  The default behaviour remains the same though, so you don't have to actually do anything unless you want to change the initialization process or the default system properties.  This easily enables developers to only initialize the functionality they want to use. Please read the documentation for more details, and a sample configuration file is now provided in the samples directory of the deployment archive.


Here is a partial list of some of the fixes beyond the ones related to the aforementioned items.

  • SMACK-387 - Allow configuration of ChatManager for handling incoming messages.
  • SMACK-403 - Add support for XEP-0297 Stanza Forwarding.
  • SMACK-343 - Fixed OSGi manifests.  All jars are fragments of smack.jar.
  • SMACK-339 - Allow ConnectionListeners to be added before Connection is connected.


In addition to these changes, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.

As many know, there has been a push in the community to move our VCS from subversion to git.  I agree with them that it is time to make that move, and I hope the other contributors and especially the project leads will get on board. I had reservations about making this move myself, not so much specific to git itself, but for the fact that I didn't think that it offered enough advantage over the cost of actually doing the move due to the limited resources available.  If we were all paid to do this kind of work, these issues simply wouldn't exist.  It isn't simply switching version control, but the interactions between that and the existing infrastructure (Jira and Bamboo) and the like and also implementing new software, build and release processes.


With regards to the software development process, this is where git, or more specifically, some of the available management tools for git really shine. They add more than enough value to the process that I think we should adopt them.


So, I am proposing that we get and set up Atlassian Stash (the enterprise version of BitBucket).  It has excellent integration with the existing development tools we are using and will provide a much better software development and management process then we currently have (which admittedly isn't that hard).


  • Branches can be linked to their Jira tickets.
  • Code review of a pull request will automatically update a Jira ticket to code review status.
  • Accepting a pull request will update the status to resolved.
  • Configure builds to automatically build any branch.
  • Force merge of pull request to require a successful build before allowing a merge.
  • Inline code reviews
  • Would allow private repos
  • Can be branded to Igniterealtime


From what I know, the feature set is very similar to Github, but I don't know where Github stands with respect to Jira and Bamboo integration. I am sure the build server has no issues either way with simply building the code base, but I have no idea if it offers any actual integration the other way around.

Smack 3.3.1 is released

Posted by rcollier Champion Oct 7, 2013

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.3.1).  It is now available for download.  This is a minor release and there have been a few bug fixes, most importantly, the memory leak in the keep alive process and one new feature. This is a partial list of the more important items.


  • [SMACK-441] - Memory leak in KeepAliveManager
  • [SMACK-447] - Compression is not enabled for Java7ZlibInputOutputStream
  • [SMACK-448] - Java7ZlibInputOutputStream does not work. Deflater.DEFAULT_STRATEGY is used as compression level when it should use Deflater.DEFAULT_COMPRESSION
  • [SMACK-450] - VCard.load() throws null pointer exception if there is no VCard for the user
  • [SMACK-455] - Multiple items doesn`t not parse correctly in a pubsub message
  • [SMACK-369] - Exceptions during login should get thrown back up to the caller.


In addition to these, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.

Smack 3.3 is released

Posted by rcollier Champion May 4, 2013

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.3).  It is now available for download.  There have been a large number of issues addressed for this release, including new functionality with support for several more protocol extensions (XEP's) and many improvements on existing features.

        New Features

  • [SMACK-331] -         Add support for XEP-0184: Message Delivery Receipts
  • [SMACK-345] -         Inproved detection of last activity
  • [SMACK-361] -         Add support for XEP-0115 Entity Capabilities
  • [SMACK-376] -         Setting a custom trust manager to control certificates from outside
  • [SMACK-388] -         XEP-199 XMPP Ping support


In addition to these, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.

Release of Smack 3.2.2

Posted by rcollier Champion Feb 6, 2012

The latest version of Smack is now available for download.  There have been several bugfixes related to file transfer and minor improvements in this version.


Barring anything being broken specifically by this release, the next version of Smack will be 3.3, there are no plans for a 3.2.3 version.


Here is a list of issues resolved in this release.


  • SMACK-263 -         Set file info in all send* methods
  • SMACK-338 -         IBB filetransfer doesn't work as expected
  • SMACK-346 -         Bug in return code for rejection handling in FileTransferManager
  • SMACK-349 -         Smack's IBB sends too much data in a packet
  • SMACK-350 -         Bytestream is not working in Spark 2.6.3 from XP to W7
  • SMACK-353 -         Thread leak in the FaultTolerantNegotiator
  • SMACK-354 -         Provide milliseconds in timestamp colum debugwindow
  • SMACK-322 -         NPE in XMPPConnection
  • SMACK-324 -         Investigate SASL issue with jabberd2 servers
  • SMACK-348 -         Documentation error - broken link
  • SMACK-362 -         smack throw NoSuchElementException if the muc#roominfo_subject has no values
  • SMACK-343 -         Make Smack jar an OSGi bundle.


NOTE: The documentation links have not been updated yet, but the jar files are available.

Release of Smack 3.2.1

Posted by rcollier Champion Jul 4, 2011

Since several defects have been fixed, including a rather serious issue dealing with file transfers.   The 3.2.1 version of Smack is released as of July 4th. 


Although more issues were planned for this release, due to number of people having issues with SMACK-338 and the slower than expected resolution rate on the planned issues, the release will go ahead with the 6 issues that have already been resolved.


  • [SMACK-129] - MultiUserChat will Store Messages in its PacketCollector irregardless of whether or not they are being read
  • [SMACK-230] - Disconnect Can Cause Null Pointer Exception
  • [SMACK-273] - Bug in
  • [SMACK-324] - Investigate SASL issue with jabberd2 servers
  • [SMACK-329] - XHTMLText uses improper format for br tag
  • [SMACK-338] - IBB filetransfer doesn't work as expected


The rest of the planned issues have been pushed to a 3.2.2 release.


Robin Collier

Filter Blog

By date: By tag: