Spelling correction to last para:

A better way would be to have an extending list (e.g. similar to the extending
list of Subversion repository locations). This would effectively form a matrix:
each row would start with a jabber ID and would have tick-boxes for 'success',
'failure' and 'change'. It would be possible to add new rows to the table and
change or delete existing rows.

It's not exactly what you've asked for, but in 0.9 and 0.11 some enhancements
for the notification profiles were done.
Is that enough for you or do you really need the matrix-style configuration?

closed as WONTFIX as reporter doesn't seem interested anymore.

Sorry - I missed your remarks of August 31st. I am still interested. Hopefully
I'll have time to take a look at this tomorrow.

I'd like to make an alternative, simpler, suggestion to the one we discussed earlier.

The Jabber plugin is really good but just a teansy bit too much hassle to configure. The 'Targets' input box currently requires a list of JIDs, each of which is a username followed by '@' and the jabber domain name. So how about changing it to allow this input box to include usernames only, i.e. with or without any @server.name suffix.

We already have a Jabber server specified in the 'Server' box in the plugin configuration panel (Manage Hudson > Configure System > Jabber panel). This provides a default value for the Jabber domain name.

So the behaviour would be simple:

• For any fully-qualified JIDs, they would be used as specified (as happens now).

• For any abbreviated JIDs, they would use the default @server.name based on the default domain name.

• When the Hudson job configuration form is saved, the new list is checked and JIDs that use the default domain name are truncated to the abbreviated form.

The benefit is clear: many teams using Hudson will be working with one local Jabber server within their company's LAN. For such teams, the full JID is not necessary because the username is unambiguous and therefore sufficient. So their usage of the plugin can be made much simpler.

I guess most people only enter a chatroom in the target list and just watch that, instead of configuring individual targets - at least that's how I use it.
So I don't see that much value in the proposed change.

If you provide a patch, however, I'd be happy to apply it.

Changed summary to reflect the updated request.

I have an additional suggestion, or one that might modify the suggested fix. We use corporate Gmail/Google Apps etc. No one uses chat rooms or group chats. Our SVN logins are driven off the same LDAP server as our Gmail data - however without the domain name. It would be very good for this plugin to operate like the email notifications, instead of the jabber server name, it would be nice to have a configurable domain. - I.e. j.blow commits to SVN, breaks build, and j.blow@example.com is sent a notification they broke the build. I thought it might have already worked like this, but apparently not, and we have to maintain each build manually with the list of people who commit to it.

Scot, as far as I understand your request, that's something different - and also something which should already be working with the 'default servers suffix'. Please open a new issue, if it doesn't with a more complete description of the problem.