powered by Jive Software

Baselining shared code base (org.xmpp and whack)

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, IgniteRealtime.org 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.

I like the idea. And since all the projects exist in the same svn filesystem, copying tags/branches/whatever is “trivial”.

To go with this question, though, is who has access to make such changes? Will that exist solely with Jive employees? Or this group?

I’m not sure what you’re asking here, but let me answer both interpretations:

If you’re asking who’s got the right permissions to execute such a change, I’d say the Jive people (I for one am not able to make the appropiate changes to SBS, JIRA, and I’m pretty sure I can’t make these low-level changes to the subversion repository setup either.

If, on the other hand, you’re asking who should have final say in wether or not we should go forward with this proposal, my answer would be: “the current leaders of the development team”. Although those people are not by definition the same people as “the Jive people”, I feel that currently only Matt and Gato would qualify. (See my upcoming comment in the “SVN Commit Access Guidelines” thread for a bit of elaboration on my viewpoint related to ‘current leaders’)

I had a quick chat with Matt last night, and he likes the idea as well. I’ll be splitting off the code in a few days.

In the meantime, we could come up with a project name, perhaps something slightly more attractive than “org.xmpp” (which is more of a package name, imho).

We could follow the -ack names that already exist, or fall back to the idea of naming projects after winds (remember ‘Pampero’? I liked that).

Any suggestions?

Xmppack Speaking about the winds. I kinda like the name Maestro. It’s a wind and also like a master of art (xmpp stanza mastering art ). Pampero is ok also. Though, maybe the name should sound similar to Whack?

There’s a number of projects with the name Maestro in sourceforge — I do like the name but I think it would be best to try to avoid a conflicting name if possible.

Xack is completely untaken. heheh Pronounced probably “Zack”. Has a nice ring to it.

XMPPCL? (XMPP Core Library)

Ok that’s about all I can come up with right now.

Guus wrote:

We could follow the -ack names that already exist, or fall back to the idea of naming projects after winds (remember ‘Pampero’? I liked that).

Any suggestions?

Well, my degree is in Meteorology, so I like winds as well! Some neat wind terms:

derecho

chinook

monsoon

haboob

daryl

How about something in the “ignite” theme?

  • tinder

  • explosion

  • flash

  • smoke

  • lighter

  • match

  • flame

Ironically, the server that runs igniterealtime used to be named chinook. We changed it to just ignite for simplicity’s sake.

Once you have a name, let us know and we’ll get the repo created.

I like Slush’s suggestion of “Tinder.” The link with the firy-theme of this community is obvious, and I like the ‘fire-starter’ implications that the name has.

I did a quick google for “xmpp tinder”. One hit that pops up is a Ruby API for Campfire. Although it’s somewhat related to chat, I think there’s enough distinction between that project and ours - I don’t feel the duplicate names would be confusing in that respect.

Thoughts?

Tinder was my favorite too. If there is another project with the name, we could go with OpenTinder to make it distinct.

Tinder is cool with me … I can’t say I “like” OpenTinder, but if that’s what works so be it. =)

XTinder kinda has a cute ring to it “ex-tinder” kinda like extender but not. =D

I agree with trying not to copy the name of another library. Especially since it’s also XMPP related. Think about a potential list of available XMPP related libraries – you’d end up having to have something like:

  • Tinder - Ruby XMPP framework

  • Tinder - Java XMPP framework

=/

hahahahah what about Thwack? I’m mostly kidding about that one.

Maybe JTinder? As this is java library. Or TinderJ

I like this idea too. Maybe we can move the org.jivesoftware.openfire.forms and org.jivesoftware.openfire.forms.spi packages also to the new lightweight xmpp libary? I plan to use them with whack and don’t want import all openfire stuff. Maybe there are more packages which are usefull for this libary?

Thanks for your initiative!

As far as I can tell, the existing project named Tinder provides an API (to a product called BaseCamp, providing webbased chat), but isn’t an XMPP implementation. It can be combined with an XMPP implementation though, which is where the Google hits are based on.

I don’t think naming our project Tinder would cause mentionable confusion. As most of us seem to agree that this name has the best ring to it, I’d like to go with Tinder.

Chris, could you have a SVN repository created by that name please? Anonymous wizards in the order of JIRA (whoever you are), can a JIRA project be created as well please?

Guenther, I’m glad that someone claims usefulness, even before we announced the project. Your use-case is what I had in mind, when proposing the project. I’ve ran into something similar before - I bet others have similar problems.

If someone finds more useful packages that should move from Openfire (or Whack - not everything there might necessarily be external component related) let me know.

I’m writing a short roadmap and project definition, which I’ll share them later this weekend.

Guus wrote:

Anonymous wizards in the order of JIRA (whoever you are), can a JIRA project be created as well please?

I sure can. Do you have a preference on project abbreviation on Jira? TI- or TN- or TD- or ZZ-

daryl

Can we go with TINDER, instead of a two-letter abbrevation? The full name is quite short in itself, and wouldn’t mess up any URLs that it’d be included in.

Right you are. I think I got it setup with you as the lead. Let me know if I screwed something up as this is my first project generated

daryl

You must be a natural. Looks perfect

For completeness sake, could you set the the project category to “Libraries” ?

I’ve published the first draft of a roadmap here: http://www.igniterealtime.org/community/docs/DOC-1844