It seems it's impossible, these days, to write a decent-sized Java application without becoming reliant on fifty different library Jar files, culled from various open-source projects.
On one hand, this is great. It's great that Java has such a vibrant culture, and is producing such a large volume of helpful libraries. It's great that if you think "Hey, I'd like to do foo", there's probably a halfway decent free implementation of foo4j waiting for you to download it. Which brings us closer to that whole 'reuse' thing that everyone's been shouting about for years.
It also makes for frustratingly fragile applications.
You've got fifty libraries. Each may depend on, or plug in to some combination of the other libraries. Each has its own bugs (quickly fixed of course), and thus its own release schedule. New releases may change dependencies on other jars. We end up building tools to deal with this complexity, but then the tool just becomes another dependency.
And, of course, each library has its own configuration file. Configuration and properties files swarm over J2EE applications like kudzu, each with its own format, and each resisting to the end any attempt at centralisation or rationalisation. Want to have one big central switch that changes your app over from development to production mode? Well you'll have to script it externally, because the necessary changes are spread across two properties– and three XML files.
(And any attempt to provide a standard programmable configurability or configuration discovery mechanism would lead to: seven or eight competing implementations, arguments on the merits of which version of IOC is best for the task, flame-wars about the JCP/Jakarta/the EFnet #java ops, and yet another damn dependency!)
And you (OK, I) end up in situations where B is throwing a NullPointerException where it's being called from A (via the helpfully provided A->B plugin). Is it a bug in A? Is it a bug in B? Is it really a bug in C, the invisible piece of infrastructure that introduced A to B? Is it some missing or malformed piece of vital configuration that neither A, B nor C have warned me is wrong? Hello, several hours of fruitlessly debugging unfamiliar fragments of Other Peoples Code.
It's enough to do your head in.
One of the things I've been working on is a component architecture for my own project, such that it cascades components. It has a default configuration that by definition *makes* *sense* for most uses, and then each component can override the default configuration, and the user has a "central configuration" that overrides the result of the default + component conifguratons, and then - finally! - if the user desires, there's a specific component-level configuration file that will override everything else. It sounds fairly complex, but it's really not, especially since the user never has to say "do this," and the components autoconfigure.
Sadly, OpenSymphony would have had this already if the opensymphony folks had wanted it. But they didn't, so they don't - and probably still don't, since they don't mind configuration hell.
You've just described problems with large-scale component oriented programming in general. None of the problems you note are specific to general.
Anyways, the solutions are pretty much common sense it's just people don't apply it.
1) No component/library should require a configuration file. It should be possible to either configure a component through system properties, a static singleton, or using javabeans. Configuration files are evil.
2) Every component should distrust every other component. Every attempt should be made sure that the correct versions are being used and the correct parameters are being passed at all times. As soon as a conflict is discovered the component should fail fast and fail hard.
3) Dependencies should be minimized. Having a lot of core dependencies (read: Jakarta) is a sign of bad OOAD.
Hah, having fun looking at your new employer's codebase I see ;)
Francisco, as a member of opensymphony I'd certainly be interested in your project, and as far as I know I never said 'bugger off, that's a dumb idea'. Finally, I certainly object to dependency hell with opensymphony (whether that objection counts or has any effect is another matter altogether)