You currently can find compiled Versions of Gojara here: http://community.igniterealtime.org/thread/51137.
Code is now updated to 2.1.5 in SVN.
In this specification, the primary Use Case for login is triggered by the server (after receiving initial presence): http://xmpp.org/extensions/xep-0100.html#usecases-jabber-login
I don’t think Gajim does anything wrong as xmpp-client - it is quite obvious that the server should handle pushing all presences to all roster contacts. For functionality like you described (“having different statuses for different gateways” this is problematic though - because the roster also includes gateway items. If the server broadcasts to these, you once again have only one status. There is probably work to be done on both sides: dont allow server to broadcast to gateway items & send directed presences to gateway contacts from client.
If you **do not **use Spark with Gojara and don’t have requirements like us you should probably have the following minimum configuration (2.1.5):
Enable persistent Roster - CHECKED
Do not add Subdomains to roster - UNCHECKED
Block presence pushing to rosterItems except gateway - UNCHECKED
To be safe you can restart Gojara after these changes (Plugins -> Restart)**
Spark wants to provide additional behaviour by making it possible to decide whether you want to connect to a gateway on startup. If you want to use this behaviour you need to CHECK presence pushing.
I hope this explains some of the situation
Some additional thoughts about this presence “Issue”: With gajim you currently should be able to send directed presences to single gateways, which of course are only forwarded and not broadcasted. A broadcasted presence to normal XMPP Contacts however will then get broadcasted to all contacts and overwrite the other statuses - this is something we could prevent with Gojara. BUT it stands in conflict with how gajim currently autoconnects to transports - which is just sending broadcast available, then letting server broadcast to gateway contacts.