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).
In the design I am talking about, this would never occur as the class wouldn't be loaded unless it was wanted anyway. This only occurs now because of the issues with static initiialization and the diffuculty of changing the built in defaults that are loaded from the embedded config file. This last part will soon be fixed anyway as I have a working version of a more flexible provider manager initializer. I still have some testing and documentation to write, but it will make it simpler to change Smack's default configuration.
In either case, I am not against having the modules, as long as there are some consolidated modules to go along with them. I know I don't want to have to pull in 20 jar files to enable the features I want to use when I can do it with a couple, especially when many of those jars will probably only have a couple of classes. It is easy to satisfy both cases though, it doesn't have to be one or the other.