I have a project right now that straddles the line on framework and pluggable program, and am worried about the sheer number of dependancies that this program rely’s on.
Currently I have this:
- Commons lang – Mainly for string utils and array utils
- slf4j – Logging facade
- slf4j-log4j – Redirects logging to log4j for GUI (note that the GUI is a module)
- log4j – Log4j itself for the above reason
- jpersist/EJP – Database abstraction layer
- PircBot – IRC layer
- A JDBC driver
- Mozilla Rhino – For Javascript plugins
In all that totals 7, even without the GUI unless you don’t want any logging. For me who’s trying to pass this off as “lightweight”, this seems like way too much.
So my questions:
- Should I limit the amount of frameworks that I am using?
- How should I distribute it? Would an independent jar for being used in other programs and a big combined jar for a single program be okay?
- Is this many dependencies normal?
That might seem like a lot of dependencies, but I don’t think it is in reality. Certainly, there doesn’t seem to be much gratuitous duplication of functionality. Most of the dependencies are doing things that you’d otherwise need to implement yourself.
Maybe you need to adjust your rhetoric. 🙂
Seriously, if those dependencies are necessary, the only way you will be able to get rid of them is to either code equivalent functionality yourself (bad idea) or drop the corresponding functionality (maybe a bad idea). Which is more important to you; being lightweight or being functional?
EDIT
Well you clearly understand the issues. The decision is yours to make. (But don’t forget that while some people are put off by “bloat”, others are attracted by lots of functionality.)
I suppose that there is a half-way solution. Keep the functionality, but make it optional and provide some way that people can configure it in / out. Of course, the downside is that this means that you have to test multiple permutations of configuration options, and it makes installation / configuration more complicated for your users.