Spring-Enabled vs. Spring-Dependent
It's getting surprisingly common for projects (e.g. Enunciate, CXF) to bundle Spring amongst their dependencies, which is creating a bit of "DLL-hell" - having to make exclusions for various versions of Spring and make sure that all the projects can agree on a particular version of Spring.
Requiring Spring to work at all makes these projects spring-dependent in a way that I'm not entirely happy with. Personally, I'd prefer them to be spring-enabled, whereby they are well-suited to being injected in your project, but can operate without Spring, and therefore, don't come with their own version of Spring with which you have to negotiate.
I'm not opposed to there being multiple modules available -- a module that is spring-enabled for projects already using spring, and a module that's spring-dependent for projects not otherwise using spring or not worried about the particular version of Spring. That seems like a handy way around the problem.
Enunciate's case is somewhat forgiveable, in that it's generating a WAR that includes Spring MVC code. I haven't investigated CXF's dependency on Spring, but it's causing some grief for a colleague.
Labels:
cxf,
development,
enunciate,
java,
software,
spring framework
2 comments:
I guess that when used as a library Spring has to be dealt with as any other library: the problems you mention are problems with the model that java currently has for every kind of jar dependency, in that they're not explicitly versioned and there is no way to segregate different versions required by different modules. Spring eases this problem by being remarkably retro-compatible, though.
It's true, this isn't only a problem for Spring - it just seems less necessary for Spring than for other projects, in that it's quite possible to spring-enable your project without being spring-dependent.
But, yes, as projects become more popular, it's an increasing problem to find different versions of that project used by different things on which you depend.
Post a Comment