<p>I'm about to inherit a rather large Java enterprise project that has a large amount of third party dependencies. There is at least seventy JARs included and some of them would seem to be unused e.g. spring.jar which I know isn't used.</p>

<p>It seems that over the years as various developers have touched upon the code base they have all tried out new project-of-the-month type libraries.</p>

<p><strong>How does one go about getting rid of these?</strong> Within reason of course, as clearly some dependencies are helpful to not have to re-invent the wheel. </p>

<p>I'm obviously interested in java based projects but I'm welcome to answers across languages that people think will be helpful.</p>

Personally, I think you have to start by assessing the scale of the problem.  It's going to be fairly painful, but I'd make a list of the dependencies and work out exactly which parts of the project use which ones.
Then I'd work out exactly what features of each you're actually making use of (in many cases, you'll end up having a massive third party library which you're using a tiny part of).
Once you have this information, you'll at least know what you're dealing with.
My next step would be to look at all of the dependencies that you only use to a small extent.  Checking around might uncover things that you could use from other libraries that would eliminate the lesser used libraries.
I'd also have a look around to see if there's anything small that you could just re-write and include in your own code-base.
Finally, I'd have a look around at the vendors of your dependencies and their competitors to see if the latest versions contain more functionality that will allow you to eliminate a few others.
Then you're just left wondering whether it's better to be highly dependent on a few vendors, or less dependent on a lot of vendors!!  ;o)