Most of our projects have a long history. This certainly goes for Spark, which was created over ten years ago. Although many of you are actively using Spark today, it is beginning to show its age. This is something that we have been planning to address for a while now.
Spark was created around the same time that the Kyoto protocol went into effect, Pluto got demoted to the status of ‘dwarf planet’ and Italy won the FIFA world cup in Germany. Thereabouts.
Since then, source code development tooling has improved a lot. Today, the Spark project is struggling to find active contributors. We believe that one of the reasons for this is that it’s pretty hard for developers (especially those that are used to work with modern tooling) to get started with our project. We have been working on that. First, we moved all of our projects from our old Subversion repository to Github. We have noticed that this dramatically improved the accessibility of our code. Second, Smack 4 happened, bringing the backbone of Spark back up-to-date.
Now, we are addressing the structure of the project itself. We will restructure the project as a Apache Maven project. This will bring a good deal of predictable structure to the project, which has many benefits. One of these is that the project will integrate easily with various development tools.
Moving Spark from its existent Ant-based structure to a Maven structure is no small task. There is no one right way of doing this. We have given it a shot and have created a structure that we think is very workable. Before committing to this structure, we would very much invite others to have a look, and comment on what we’ve done. The reasoning behind this is simple: once we’ve committed to a particular structure, it will be disruptive to change it. If we want to apply improvements, we should do so now.
Please, review our new project structure, and let us know what you think. You can find the new structure in the SPARK-1791_Maven branch on Github.
Ask yourselves: does this structure help me? Is it easier to compile the source code? Can I integrate it with my IDE of choice without too much trouble? Can I create new plugins? Does the new structure introduce a problem that needs to be addressed before committing? Can it be improved? We welcome all feedback!
@Guus der Kinderen, thanks for getting this started
I will confirm we can build our branded version of Spark ok.
Today, the Spark project is struggling to find active contributors
I think there is very much interest in Smack because of Android rather than desktop Java applications. I am not sure that this is the case for Spark. I develop Openfire plugins for a living, but no one has asked me to develop Spark plugins commercially.
Most modern tooling is aimed at HTML5/Javascript developers who use NodeJs as the middle-ware to XMPP servers like Openfire. For Spark, It is much more than tooling. Swing is outdated for developing modern user interface experiences. The Java media framework is lagging behind WebRTC and mobile apps killed the promise of Java on all platforms. My instincts tell me that Smack has a bright future, but Spark will remain a legacy application. I would like to be proven wrong
I believe that you have valid points, but I’d like to avoid turning this discussion away from the the focus point: “how do we best structure the existing code base of Spark in Maven?” Let’s focus on that for a bit.
On the one hand I like the idea about Mavenizing Spark, because yes, it helps to get started, to get the project integrated easily with most IDEs and to get it easily compiled. The Maven structure is good, but you really can’t do it wrong.
On the other hand I don’t think it will attract any developers just because of using Maven, basically for the reasons stated by Dele. Nobody is interested in maintaining a 10-year old software written with Swing, but who knows, Maven at least helps.
That said, I’d be more happy, if my 2-year old approach of Mavenizing Openfire (and your 5 year old Jira issues) would get some attention. I think it’s more useful, because more people are interested in Openfire than in Spark. The priority for Openfire should be higher here.
I believe that a majority of Openfire deployments are using spark as the client. If I’m right about that; spark becomes the face of Ignite Realtime and Openfire, because that’s what the user base is being exposed to. Only the admins are being exposed to Openfire. Also, since spark is part of Ignite Realtime, I think there is an expectation of it to be just as good/polished as Openfire.
Its been my experience that businesses prefer desktop apps. Spark also seems to be the only simple, single protocol xmpp client that can do SSO, which is a BIG PLUS for many (in business). For those reason, I believe spark needs a bump in priority. Anything that will help get some attention to Spark is a welcome move and greatly appreciated by use loyal spark users!
There’s truth in both of your comments. Spark definitely is perhaps not the most cutting-edge client out there, but it certainly does have its merits. And, unlike Openfire, it did barely get any love from developers in the past few years, so some was due.
Another reason for doing this with Spark is that I think of it as an exercise for Openfire - we certainly did not forget about that effort.
Cool. Maven definitely lowers the barrier of entry for new contributors and the life of existing developers nicer. I happen to be a Netbeans guy these days and Maven support is top notch.
May I suggest opening a PR for your branch on GitHub? It makes reviewing the change easy.
Good move IMHO. I look forward to the improvements in Spark, and the ability to resolve bugs faster that Maven should allow. And possible improvements in stability and network connectivity. Also, didn’t Pluto get re-promoted back to a planet recently?
Since then, source code development tooling has improved a lot. Today, the Spark project is struggling to find active contributors. We believe that one of the reasons for this is that it’s pretty hard for developers (especially those that are used to work with modern tooling) to get started with our project. We have been working on that. First, we moved all of our projects from our old Subversion repository to Github. We have noticed that this dramatically improved the accessibility of our code. Second, Smack 4 happened, bringing the backbone of Spark back up-to-date.