Baselining shared code base (org.xmpp and whack)

Yeah. I dont see the Tinder project in JIRA.

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.

I think I got it now wroot.

daryl

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

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?

Guus wrote:

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 have added you to the whack-developers group

daryl

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).

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.

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.

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.

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.

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:

  1. In the MUC search I’ve got … test@conference.domain.lt… as an result and I think the field type should be jid-single. I think maybe in the DataForm#addItemFields(Map<String,Object> fields) method there should be a possibility to specify the field type.
  2. In my component I’ve to add a collection of FormFields to a DataForm (extended disco#info features) and don’t know howto do this now. Can you give me an advice or can you add a method like DataForm#addField(FormField)?
  3. At the DataForm and FormField class you use the String method isEmpty() which I think is not JDK15 compatible maybe we switch to JDK16?
    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?