Dependency Management Again

So I’m sitting here assembling a quick little Eclipse project that provides a Hibernate API for a bunch of already-existing tables. As I’ve done a lot lately, I used a Spring/Hibernate DAO construct.

Since this is a fairly discrete piece of functionality, I put the code in a brand new Eclipse project, and started loading up the jars I needed. A lot of times, I just drop in spring.jar, but knowing that that’s a pretty big jar, I decided to only include the bits I needed.

So, reading Spring’s readme file, I tried to figure out what jars I needed. Me, I would find this stuff much easier to take in as a picture rather than as a block of text, but based on what I read, I sketched out the following picture:


(This is based on the “Artifact” UML type — one of the new things that appear in UML 2 deployment diagrams. Personally, I’m not a big fan of UML as a mechanism for designing things, but I love UML as a tool to describe what’s been created, and I wish wish wish that more products would provide dependency pictures like this).

So those were the jars I added to my project. I created the DAO, slapped together a Unit test, and it failed. Missing dependency, it seems. A LobHandler class found in spring-jdbc.jar. So I went back and re-read the Spring documentation. I can’t figure out why spring-jdbc is required, but it seems like it is. I add the jar.

Run the test again. Another failure. This time it’s looking for something in the spring-orm jar.

And at that point, I kinda have to shrug my shoulders and conclude that the dependencies for Spring just aren’t documented correctly and I add a 1.8 Meg jar file to my Eclipse project because people are just not very good at understanding and managing dependencies.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply