I use spark a lot and love it. I also love OpenFire. It seems that OpenFire gets all the love from the current devs (and for good reason, I don’t know of many other XMPP servers that are as good as OpenFire – Good work guys!).
What needs to be done to move Spark forward? It hasn’t had a new build/version since 2011… It’s still packaged with java6, and there are things that should get fixed with it.
I’m able to help out with the project (Java development), but don’t know where to start or who to talk to?
A little about me - I’m a Systems Admin by trade but also do a lot of Java development - I’m self taught and have been doing Java for about a year now. I’m currently taking courses that cover java as part of my degree. I’d love to get into an Open Source project and help out. I do work full time and go to school full time, so I can’t dedicate a ton of time to the project, but I’ll do what I can.
The company I work for runs OpenFire and Spark at the office and I ran an OpenFire server from home until some recent ISP issues… so I’m pretty familiar with the “user end” of these projects.
I’m more-or-less the community organizer and can get you setup with permissions to start developing Spark. The first step would be to elevate your privs in http://issues.igniterealtime.org and have you start triaging tickets. I can get you svn acess as well. Do you currently have access to Jira?
the Spark project gets regular bug fixes from two teams. The client runs nicely on Java 7, but a J7 release is stopped by two things:
We need the Bamboo build server to integrate the jre7. This might be trivial, but no one has time to investigate this.
We need to figure out how to build for the Mac plattform. Again, might be simple, but no one who ca do this.
Actually the Spark trunk has several fixes that makes it worth while to release and my company (I am in in a similiar situation than you) is using the trunk as release base for 15000+ named users.
Moving Spark forward is not restricted. If you want to start, get your hands on the code and start with some simple bug fixes. Publish those in the forum as diff, we will review and commit. Ultimately, we let you commit to SVN, but that access has to be earned.
Spark is the base for at least one commercial plattform and those guys depend on the trunk and they fix stuff too. Hence I respect stability.
At my company people are getting tired of the old jabber client we still use. And i would be happy to propose Spark for a replacement (i’m using it myself full time), but that Java6 focus stealing bug would be a huge issue, though i myself don’t care about it much. But it looks that too many things has to be solved to move to Java7. There are some other minor issues, or maybe things that i don’t know about until it is deployed in a broader scale.
Jason, any help would be welcome and Daryl already said where you can begin. Welcome to the community.
Over the last year or so we worked with Walter’s team to improve on Spark. We use it as the base of a commercial product that morphed into a fully featured communications client, merging XMPP with SIP for IM/presence/voice/video/screen sharing on Windows, Mac, and Linux platforms. Our server side solution is available in open source at SIPfoundry.org. We have not forked Spark, but contribute all the changes back except the plugins we created to skin it and add the SIP capabilities. Our server side solution also includes Openfire as the XMPP server, tightly integrated with the SIP side an we are behind OF-583, changing the providers in Openfire to accommodate different databases, among other things. Contact me if you are interested to hear more.
I agree with Walter, as this is the current guidelines we have for becoming a contributor. Fix some bugs or make some additions and post the patches here. If there are multiple contributions and the code is up to par, then direct commit access can be granted.
I have never used Jira, just a heads up, and am not really familiar with SVN as I typically have used GIT for all my stuff. I have no problem “earning” SVN access as this will reduce the probability of me screwing up things.
I suppose the next logical question is where am I needed most?
I guess I can just take a look at the bugs list for Spark and tackle one’s I feel I can do?
I could do whatever is needed at the highest priority I suppose. It’s probably best to start with easier stuff then move up as I become more familiar with the Spark codebase…
Also, as a heads up, I’m new to developing stuff in a team… so please be patient with me as I learn your processes. I typically have developed things for my company alone.
I know the Copy/Paste problem, File transer problem, and Window focus problem are the issues that people at my company complain the most about. I’ll take a look at the current bugreports at issues.igniterealtime.org and see which ones I can start tackling…
I dont’ have access to a mac…
but do have a Win8 64bit box, Win7 64bit box, winXP 32bit box, and several Linux boxes ranging from server (CentOS) stuff to full desktops (Fedora)… so I can test on this range of software.
two of the issues you are talking about have been investigated and fixed. File transfer is an issue in Smack/Spark that is fixed in 2.7.0. Note that we intentionally break 2.5.8 to 2.7.0 transfers in certain circumstances (there is a discussion thread about this IBB vs Bytestreams) to become compliant with XMPP standards. Overall file transfer is far from being simple (I had someone working on it for months).
The stealing focus is solved as soon as you bundle a Jre 7 with Spark. If you need that for company purposes, it is fairly simple to solve, if you purchase a the packager install4j from ej-technologies and re-package the current trunk.
I would propose that you start out with building and packaging for Spark for your company purpose and move fixes to the community. That’s the way we are doing and that helped a lot to get test coverage and quality in a nice way.
The current trunk is in production at my company for more than 2000 users. It’s fine and stable.
thanks. That’s one part the other one is to find someone who understands bamboo and take the time to fix the build process. I don’t have capacity for that in my team (as we are bound on GoJara/Spectrum and the internal Go Live mid February).
It was intersting getting the project into Eclipse, but after I figured out how to get the project to build it was smooth sailing.
Question:
Do you guys mind if I put the project into my github? (including all licensing, etc). It would be much easier for me to maintain my own branch while tinkering with bugfixes. I understand if this wouldn’t be allowed…as it would have to be a public repo since I can’t justify paying for private repo’s at the moment.
Also, what is JiveSoftware’s/IgnireRealtime’s current role in Spark and OpenFire? It looks like Spark was built originally as proprietary software and then opensourced?
just a thought – could Mac support be dropped or instead just a Spark.jar file released, which would run on whatever native JRE is installed on the machine? This would bypass having to package java with spark for systems that are proving to be more difficult (such as mac). It wouldn’t be as elegant of a solution as the installer i suppose, but may help speed up the next release…
Also, what is JiveSoftware’s/IgnireRealtime’s current role in Spark and OpenFire? It looks like Spark was built originally as proprietary software and then opensourced?
Jive is hosting this website and services (like JIRA, Bamboo, Fisheye, etc.). IgniteRealtime is not a company, just a name for this place. Yes, Spark and Openfire were not open source originally and Openfire even had an Enterprise paid version with additional plugins, which are now open sourced also. Then Jive gave them away
Looks like Jive went in a different direction then, since I can’t even find references to WildFire/OpenFire or Spark and assoctiated technologies on the jivesoftware website… mighty nice of them to opensource it instead of killing the project, OpenFire is really nice.
A real SSO that do not need password authentication once a domain user is already signed in to their account.
A fix to alert users of unread messages they might have missed if their session unexpectedly ends. This can happen if Windows unexpectedly shutdown or Spark shutdown for other reasons before the user open their massages.