I have been attempting to mavenize Smack, and I have come up with a few questions and suggestions related to how Smack is deployed. Currently there are 4 jar files as artifacts from the build process, smack, smack-debug, smackx and smack-jingle. My question is, why? Can anyone enlighten me as to why there is this separation?
A part of converting to maven, I would like to create 1 or possibly 2 artifacts only.
smack - which would be everything currently in the aforementioned 4 jars.
smack-core - This is assuming that someone would need access to core xmpp functionality without any of the extensions.
The intent is to get these deployed to the central maven repos along with the upcoming release of a 3.2 Beta.
I am hoping for some feedback here first, and then possibly putting a similar type post in the open forums to hopefully get more user feedback. I look forward to your suggestions/comments.
Can we split things up and hold of mavenizing Smack until the next (post 3.2) release? I’d rather have a “compatible” release out first, allowing existing users to update to the latest codebase in a way that they’re familiar with. After we get the majority of the changes out, we can do a release without a lot of functional changes, but one that introduces a restructured project. For that release, we can focus completely on updating documentation and educating new and existing users to make use of the new framework. Divide and conquer!
As for the multiple libs - I don’t know of a good reason to keep them around either.
Sounds good to me. There are a couple of issues with some of the dependencies in the current build that I would have to sort out anyway and I wouldn’t want it to delay a release because of it.
We’ll just put that one on the roadmap for the future.