May 30, 2009 2:46 AM
Baselining shared code base (org.xmpp and whack)
-
Like (0)
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:
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.
How about something in the "ignite" theme?
* tinder
* explosion
* flash
* smoke
* lighter
* match
* flame
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
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" ?
Thanks, I made the switch, but keep thinking I am missing something to get it to appear on the main Jira console. Still messing around with it.
daryl
Yeah. I dont see the Tinder project in JIRA.
I think I got it now wroot.
daryl
Repo/sub-dir created!
https://svn.igniterealtime.org/svn/repos/tinder/
I attempted to add everyone on this thread to the 'tinder' group which has RW access (Guus, Daniel, etc), but couldn't easily locate svn accounts for wroot, Daryl, slushpupie or Guenther. Do you guys have svn accounts? If not, I can create them.
Daryl, yes, i see it now.
Chris, i'm not a coder, so probably i dont need svn rw access. It's enough i can easily mess up my local Openfire source copy ![]()
slushpupie already has an account i believe, maybe under other name, like Jay.
I believe you can create an account for Daryl, as he's doing some patching. Though i'm not sure about the Tinder, he usually patches Openfire.
And Guenther should get a mentor first and pass his trial period. Though, i would give him svn access right away, if everyone agrees. We need good and commited coders badly here ![]()
I've published the first draft of a roadmap here: http://www.igniterealtime.org/community/docs/DOC-1844
Could you guys comment on this draft of an introduction to the new Project? I'm not that much of a writer, I'm very open to suggestions...
That's odd. I'm not allowed to view the content of the document that I just created. Did I mess up something in the SBS collaboration settings?
It's 1844 ![]()
But it seems 1844 is version 1.
I've published two documents: DOC-1844 and DOC-1845. One is a roadmap, the other one is a project description / introduction.
Then something is wrong and maybe Benjamin can look into this.
Should now be fixed.
Works again for me, tx!
I've added the sources for Tinder in the new repository (
TINDER-5) and replaced code in Openfire with a jar generated by Tinder (
OF-1). I'd like to do the same for Whack, but I'm not able to create a JIRA issue for Whack.
I'd love some feedback on the new project. Guenther, would something like this suit your needs? Any suggestions for improvements?
I'd love some feedback on the new project. Guenther, would something like this suit your needs?
Thanks, it looks awesome! I think this should make my future development easier.
Any suggestions for improvements?
In my opinion we should soon move the packages to org.jivesoftware.tinder since at the beginning its easier to migrate such thinks. And maybe you can have a look to JM-1536 (a patch for XMPP Core RFC, section 9.3.4: Application-Specific Conditions support).
I thought of renaming packages to something that reflects the new project name, but in the end, I opted not to do this, as this'd break backwards compoatibility. Then again, as long as we keep the class names intact, fixing all imports would be quite easy (if you're using Eclipse: CTRL-SHIFT-O on the project root would do the trick).
I'd like to rename the packages, as it looks better and would prevent some confusion, but in the end, it's mainly cosmetics.
I would really like some input from the Openfire developers (Matt, Gato) on this.
I've moved JM-1536 to the Tinder project - I'll have a more thorough look later this week.
I thought of renaming packages to something that reflects the new project name, but in the end, I opted not to do this, as this'd break backwards compoatibility.
Hmm, yes backwards compatibility is a good reason for leaving the name. In my opinion such a change should at least cause a new big relaese (Openfire 4.0) but maybe it's time for a new relaese since the JIRA is also reseted. But this should decide Matt or Gato.
I had another look in the Openfire sources and think maybe your org.jivesoftware.openfire.resultsetmanager packet could also move to tinder?
RSM is a good candidate indeed. I moved it.
I still didn't make up my mind on the 'rename packages' thingy. Suggestions, anyone?
I had a quick chat with Matt yesterday. We'll stick with org.xmpp as a package name.
BTW, after doing all the changes and making Roadmap and Project overview docs public this should be posted to Product Releases and News sub-space (with the links to these docs) and probably should be mentioned in the next Openfire version changelog.
Yup, that's what I had in mind too. I'd be nice if we had our own SBS community/area for Tinder.
I'm waiting for the project to mature a little before I'll announce it though.
Project Tinder is at a point where I feel comfortable to release it for the first time.
Does anyone want to comment on something before we release? Is there anything left to do?
Who can provide the usual project space in SBS and who can make some modifications to other IgniteRealtime.org pages (such as the download page, view source pages)?
Guus wrote:
Is there anything left to do?
Well, to make a party!
Congrats about the good work and first release coming ![]()
Project Tinder is at a point where I feel comfortable to release it for the first time.
Cool, congratulations! ![]()
Does anyone want to comment on something before we release? Is there anything left to do?
Yes, I've tested the actual svn version 11068 and have some issues:
Thanks for your work!
Good find! I had my workspace set up with the default Java 6 JRE. I adjusted my setup, and replaced the String#isEmpty() instances.
You wouldn't be able to add FormFields the way you're describing, as the FormField constructor is package protected. I'm not sure why this was done, but I left it as is for now. You can add FormFields to your DataForm using one of the two overloaded DataForm#addField() methods. Both methods return the FormField that was created. You can then modify that instance using the setters in FormField.
The DataForm and FormField implementations haven't been modified a lot by me - we could do so in the future though. The problem that you identified with the addItemFields() method is a good example of something that could be improved.
Two things of notice, regarding your muc-search related comment: I'm not sure how the type="text-single" attribute got added. It doesn't appear to be added in the code. I'll have to look a bit deeper into the code, but could you check your client (does this add that attribute itself, perhaps? After all, "text-single" is the default value for a type.
The second point: for results, the type of the result can (should?) be added to the "reported" field. That'll prevent us from having to add this attribute to every item (which is quite redundant). The "reported" fields for those columns should be changed from "text-single" to "jid-single" (see
OF-4).
You wouldn't be able to add FormFields the way you're describing, as the FormField constructor is package protected.
I used the org.jivesoftware.openfire.forms package before and then I switched to org.xmpp.forms. Maybe this feature should be added to org.xmpp.forms since org.jivesoftware.openfire.forms is now deprecated.
Could you check your client (does this add that attribute itself, perhaps? After all, "text-single" is the default value for a type.
Yes, it was curiously added by Psi in the XML console, in Pidgin I didn't see it.
One other thing, I like the move from org.jivesoftware.openfire.resultsetmanager to org.xmpp.resultsetmanagement, but I think this could also breakbackwards compatiblity for Openfire plugins. Maybe add a copy to the origin place and mark it also as deprecated?
I can make all changes that don't require me to create an icon or do graphics work. ![]()
Chris and I have just started working on the build server which will likely be where we build releases for the various projects. So, we could wait till that is building, or since this is a library and not big, per operating system, packages like Openfire, we could possibly move forward with a manually compiled build.
As you guys might have noticed, the first release of Tinder was done late last night (my time). A big thank you goes out to Benjamin - he put a lot of work in updating the website to include Tinder everywhere!
Thanks for all the feedback on the initial project idea guys! Lets continue discussions on Tinder in the new SBS community that was created for the project.