Knowing the dependencies amongst your jars.

It may happen often that we include a bunch of jar files in our project, but not sure about their usage. We do it many a times as we want to avoid any unforseen errors, and most of the times just for saving time’s sake which we have to spend examining each’s utility.

I too did the same, until yesterday when I intentionally started removing the jars whose utility I couldn’t directly see, and there awaited a lot of surreal surprises, and of course a plethora of errors, which I don’t normally see, all because of an inquisitive idea!

This post will again extol maven. There were days when I would just loath this word, for it required me to change my directory structure and write an additional file, POM. But gone are those days, and my ignorance about it.

Let’s take a sample POM.

<project xmlns="" xmlns:xsi=""

Now when I save it in STS, the maven plugin downloads these dependencies and adds them to my classpath.

So, no surprise there, four dependency declarations and four dependencies listed above.

Now, add one more dependency to your POM and save it.


We just added a spring-context dependency to our project. Now we’ll see the dependencies included in the project with the inclusion of this new one.

What in the world???

We just included one single dependency!!

From where have all these come from?

It’s okay, don’t panic there’s no error, or virus for that matter. 🙂

By now you must have guessed, these extra jars are the dependencies of spring-context dependency. Spring-context depends on them directly or indirectly, so you have to include all those in your classpath but if you use maven, it’ll do it automatically for you. 🙂

To know it in a more detailed manner, type

mvn dependency:tree

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building spring-aop-sample 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ spring-aop-sample ---
[INFO] ankeet.spring.aop:spring-aop-sample:jar:1.0-SNAPSHOT
[INFO] +- org.springframework:spring-context:jar:3.1.0.RELEASE:compile
[INFO] | +- org.springframework:spring-aop:jar:3.1.0.RELEASE:compile
[INFO] | | \- aopalliance:aopalliance:jar:1.0:compile
[INFO] | +- org.springframework:spring-beans:jar:3.1.0.RELEASE:compile
[INFO] | +- org.springframework:spring-core:jar:3.1.0.RELEASE:compile
[INFO] | | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] | +- org.springframework:spring-expression:jar:3.1.0.RELEASE:compile
[INFO] | \- org.springframework:spring-asm:jar:3.1.0.RELEASE:compile
[INFO] +- cglib:cglib-nodep:jar:2.2.2:compile
[INFO] +- org.aspectj:aspectjweaver:jar:1.6.12:compile
[INFO] +- org.aspectj:aspectjrt:jar:1.6.12:compile
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.297s
[INFO] Finished at: Tue Dec 20 11:32:02 IST 2011
[INFO] Final Memory: 5M/15M
[INFO] ------------------------------------------------------------------------

So you can see how spring-context is dependent on spring-aop and spring-aop inturn is dependent on aopalliance.

There are several other useful goals of this maven dependency plugin like analyze. You can check them here.

I hope you’ll too have fun discovering the very jars you unknowingly used and their obscurely hidden interdependencies. 🙂


2 thoughts on “Knowing the dependencies amongst your jars.”

  1. Nice!
    Generally during scanning these are the steps that may take place depending on the third party plug-in being used:
    1. Scan for Direct Dependency
    2. Scan for Indirect Dependency
    Direct Dependency: Ever class in the project, their methods, data-types of the fields are all scanned to check if they are referring to any other class (or library); and correspondingly all those libraries being referred to are checked for an entry in the .classpath during compile time and file during run-time.
    Indirect Dependency: This is generally the second iteration of scanning relationships among the different classes, methods and other libraries used in a project indirectly i.e. a method or class in the project being built or run is using a method of another third-party lib which in turn depends on another library for it to perform correctly.
    The manifest file has something called the “Implementation-Version” through which a control is kept on the version of the library or project being used. It may happen a particular version has introduced a method which was not there in the previous version. Then despite using the latest library if the manifest file is still referring to the old version, the application may fail at runtime.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s