We have some common code laid out in packages as expected.
Some of these packages are
handler, processor, util, registration etc
Common here means these will be re-used across multiple Java / Java EE projects which are unrelated to each other.
The question is on packaging for distribution.
Each package comprises a different functional units but put together, they are an API.
Should we bundle individual functionalities into a JAR and end up with say 8 – 10 jars.
eg: handler jar, registration jar etc
or
Should we take the least common denominator approach which is a Base Build of 5 compulsory packages into a single jar.
Any one else needs that jar as the base and can choose add-on jars.
Our build system is Ant + Ivy and these dependencies will be resolved at compile and build time.
Unless you have lots and lots of API classes (think Spring) or aware of some interference among them, it is my opinion, that there is very little reason to break them into separate jars. The only other reason to break API in separate jars is to enable different teams work independently.
Managing single jar simplifies a lot of things and it does not worth fixing the problem that does not exist.