I am going to address most of your points, but I am going to leave the VCS discussion for a different post, as IMHO this is something that should be an Igniterealtime wide initiative and I would like to keep this discussion Smack specific.
There is no reason why this should become an igniterealtime wide initative. Most other projects besides openfire and spark are dead. And Gus, the openfire dev, already stated that he doesn't want git.
The modular build is a nice idea… That being said, maybe there are advantages such as a smaller footprint that do outweigh that extra complexity.
It's not only the smaller footprint. If a user has the option to *not use* components he wouldn't suffer from their defects (e.g. because they have memory leaks).
This is definitely something that can and should be discussed.
Creating a modular Smack is a core objective of the GSOC proposal.
As a side note, I would also have a separate module(s) for anything that has not reached the Draft state of the XEP process (as I mentioned once before), which would mean, for example, pulling out the existing workgroup implementation.
The idea is to create a module for every XEP. And those modules carry metadata, such as their current status and type.
I was thinking that moving Smack 4 to Stax might be a good idea just to remove the external dependency on the pull parser. I haven't inverstigated this though to determine whether that is actually a good idea
No, it's not an good idea. We need an abstract parser that can be imlemented by the 3 different pull parsing implementations: XPP3 for non Java7, Stax for Java7 and MXParser on Android. That's the other core objective of the GSOC proposal.
I notice that you are proposing Gradle as a build system instead of Maven, I know very little about Gradle, so I am wondering what the advantage is of this over Maven in the case of Smack. My preference right now would be Maven for three reasons,
- it is much better known (obviously due to its maturity)
- it has excellent IDE support (this is a big one in my opinion)
- I know it
I think Gradles flexibility makes it better suited for the job and therefore I prefer it over Maven. Also. it is more powerful and supported by (most?) IDEs.
I see we have different ideas regarding the future of Smack. I think we need a modular build system provided by gradle and an abstraction for some components of Smack so that Smack can be deployed on various platforms.
You propose to remove the static initializers including of a rewrite of large parts of Smack and keep Smack monolithic for some reason.
I hope that's an accurate summary of the situation.