Guus der Kinderen

Baselining shared code base (org.xmpp and whack)

Discussion created by Guus der Kinderen Champion on May 30, 2009
Latest reply on Jun 22, 2009 by Guus der Kinderen

Hi all,


There is a couple of components in several projects that have a shared, but duplicate code base, notably 'org.xmpp' and Whack. I propose to remove this code from these projects, and create a dedicated project for each.


There would be a couple of advantages to this:

  • Obviously, remove duplicate code. This will make it easier to maintain and develop the code properly.
  • It'll be a lot easier to "do things" with these light-weight projects - not only for us, but also for developers of third-party products. For example, having a lightweight XMPP stanza implementation project (what's now org.xmpp) could be very interesting for a variety of projects. The value of a stand-alone Whack project might even be more obvious in this light (note that the Whack project itself would use the 'org.xmpp' project).
  • Lastly, as these are 'core' libraries, they deserves a bit of 'dedicated' attention (unit tests, bugtracking, stuff like that). This would benefit any attempt to really fine-tune the code, for example for high-performance tuning. Currently, the code is a bit put in the shadows of the other projects (of which they are part of).


The amount of effort and resources to go into this change are limited, while the benefits will be considerable. As development of other projects is a bit at a stand-still right now, this might be a good moment to perform these changes (as they currently wouldn't interfere with any other development).


I would suggest a set-up like this:


Move the "org.xmpp" and "whack" projects into SVN repositories (a new one will need to be created for 'org.xmpp'). Let's create a tag for the current trunk of 'Whack' for future reference. Simultaniously, rip out the org.xmpp and whack sources from all other projectsto remove any duplicate code. Replace it with a jar, produced by the new project. As we currently have duplicate code, I expect some oddities to pop up here.

Next, lets get an "org.xmpp" project in JIRA. Finally, should get a new project as well. The Whack project documentation should be modified to reflect the changes.


After the SVN and JIRA projects are in place, we should develop some unit tests that verify and validate both projects. Now that we've seperated the build process from any other project, these tests can go in easily. As the projects are now 'stand-alone', developers should be encouraged to actually pick up development. If they do, the new tests should help making sure that nothing gets tipped over.


I've made the code modifications before (I've suggested this before, but that attempt died a silent death somewhere) - it's all pretty do-able without to much effort.


I'm aware that proposing something like this often equals to volunteering for the job I'm perfectly willing to take this on, although I need some help with Jive people to get the JIRA, SVN and SBS set-ups in place.


I intentionally left one idea that I'm having out of this proposal. Although I think it'd be beneficial to implement, I think we should discuss this outside the scope of the above proposal: add proper dependency management (including perhaps a continuous integeration setup) to the IgniteRealtime projects. This would have a number of benefits, both for us, as for developers that might want to use our products. As I said, I rather discuss these in some other place. I'm mentioning them here, because I proposed to create a couple of new projects. With easy dependency management in mind, I would like to create these projects in the default Maven directory structure. This doesn't require us to actually use Maven (it's simply a directory structure that I'm proposing) but it would make it very easy to switch to Maven later, if we would like to do that somewhere in the future.