I'm currently trying to make a case for adopting dependency management for builds (ala Maven, Ivy, NuGet) and creating an internal repository for shared modules, of which we have over a dozen enterprise wide. What are the primary selling points of this build technique? The ones I have so far:

  • Eases the process of distributing and importing shared modules, especially version upgrades.
  • Requires the dependencies of shared modules to be precisely documented.
  • Removes shared modules from source control, speeding and simplifying checkouts/check ins (when you have applications with 20+ libraries this is a real factor).
  • Allows more control or awareness of what third party libs are used in your organization.

Are there any selling points that I'm missing? Are there any studies or articles giving improvement metrics?

  • 1
    I think you've nailed it. Nov 7, 2012 at 14:31
  • 4
    I will never get back the many hours of my life wasted on broken Maven setups. I've become convinced that regardless of the good intentions, in a large corp, it will eventually become an unmaintained mess that sucks the life out of you until you're a hollow shell.
    – MrFox
    Nov 7, 2012 at 15:57
  • 1
    @suslik Care to elaborate on what a "broken Maven" setup is? Nov 7, 2012 at 21:33
  • 1
    @AndrewFinnell Say there's 5 groups working on projects that you need to pull in for your build to compile, and because of poor coordination everyone ends up depending on different versions of libraries. Then it turns out one of the projects was not meant to be 'released' yet but (no one told maven!) you have a dependency you need to satisfy. This isn't 'supposed' to happen, but the automatic resolution makes it too easy. If everyone had a /libs dir to maintain in svn it would force people to stop and ask questions before things get out of hand.
    – MrFox
    Nov 8, 2012 at 15:02
  • 2
    @MrFox That is indeed because of poor coordination, not Maven dependency resolution. I've experienced same situations and I'm not a fan of Maven, but I think that tools aren't supposed to solve human-related problems like premature releases, lack of communication, lack of testing, poor maintenance, etc.
    – scriptin
    Nov 30, 2014 at 10:00

3 Answers 3


I'm not 100% sure on the positives. Here's a few negatives

  1. You often end up adding dependencies to 3rd party servers/endpoints that might not be stable.

    I've had it happen with bower that the repo of some dependencies was deleted or moved. So a new dev comes along, clones my repo, types bower install and gets errors for un-accessible repos. If instead I had checked in the 3rd party code into my repo that problem disappears.

    This is solved like the OP suggests if you're pulling deps from copies kept on a server you run.

  2. Harder for noobs.

    I work with art students with very little command line experience. They make art with Processing, arduino, Unity3D, and get by with very little tech knowledge. They wanted to use some HTML5/JavaScript I wrote. Steps because of bower

    1. Download Zip of repo from github (notice that's on the right of every repo on github. Because they don't know git)
    2. Download and install node (so we can run npm to install bower)
    3. Install git or msysgit (because bower requires it and it's not installed on many students' machines)
    4. Install bower (npm install -g bower)
    5. bower install (finally to get our dependencies)

    Steps 2-5 can all be deleted if we just check in the files to our github repo. Those steps likely sound super easy to you and me. To the students they were very confusing and they wanted to know what all the steps where and what they were for which might be good learning possibly but was entirely orthogonal to the class topic and so likely quickly forgotten.

  3. It adds another step when pulling.

    It's happened many times I do a git pull origin master and then test my code and it takes 5 to 10 minutes to remember I needed to type bower install to get the latest deps. I'm sure that's easily solved with some pull script hook.

  4. It makes git branching harder

    If 2 branches have different deps you're kind of screwed. I suppose you can type bower install after every git checkout. So much for speed.

As for your positives I think there are counter examples to each of those

Eases the process of distributing and importing shared modules, especially version upgrades.

vs what? It's certainly not easier to distribute. Pulling one repo instead of 20 is not easier and is more likely to fail. See #1 above

Removes shared modules from source control, speeding and simplifying checkouts/check ins (when you have applications with 20+ libraries this is a real factor).

Conversely it means your dependent on others for fixes. Meaning if your deps are pulling from a 3rd party source and you need a bug fixed you have to wait for them to apply your patch. Worse, you probably can't just take the version you want plus your patch, you'd have to take the latest which might not be backward compatible with your project.

You can solve that by cloning their repos separately and then you point your project deps to your copies. Then you apply any fixes to your copies. Of course you could also do that if you just copy the source into your repo

Allows more control or awareness of what third party libs are used in your organization.

That seems arguable. Just require devs to put 3rd party libraries in their own folder under <ProjectRoot>/3rdparty/<nameOfDep>. It's just as easy to see what 3rd party libs are used.

I'm not saying there are no positives. The last team I was on had > 100 3rdparty deps. I'm just pointing out it's not all roses. I'm evaluating if I should get rid of bower for my needs for example.

  • Wow, lots of negative votes and not a single justification for them. Good Job! :(
    – gman
    Nov 26, 2014 at 7:35
  • I've never used bower, but the need to install each time you checkout seems like a design flaw. It should check it's config when it builds a project: if there are changes, it should rebuild from scratch. Also, moving repos is irrelevant to Maven, since it pulls artifacts from Maven repository, which which stores artifacts, not the actual repos with code. You can only change artifactId and groupId in the next version of your artifact if you publish it in Maven repository. So, your points #1 and #4 are mostly irrelevant to Maven particularly. #3 can be replaced with mvn clean (sometimes)
    – scriptin
    Nov 30, 2014 at 12:25
  • While being true, #2 is not a disadvantage - it's a trade off. Of course, you have to learn your tools! For example, Git is pretty hard to grasp, but I'm not going to give up on it because of dem noobs.
    – scriptin
    Nov 30, 2014 at 12:33

Take a look at The Twelve Factor App

In particular read about what they have to say about dependencies. You will notice that good design provides a declarative mechanism for locating dependencies, in Java this is often realised through Maven. Ivy and NuGet work fine, but Maven is currently the leader in the field and Ivy is decidedly hard work.

If you adhere to the Maven release process (develop snapshots until a formal release is ready, never try to overwrite a previous release, use a proper repository manager like Nexus or Artifactory) then you should have a build process that hums along nicely.

Once you have a solid declarative build process in place, it opens the door to other good practices such as Continuous Integration with Jenkins, Continuous Code Analysis with Sonar and you'll find yourself looking for a better version control branching strategy using git.

Each of the above builds on the core that is Maven. These days, it is pretty much a no-brainer decision.

  • I looked at The Twelve Factor App, but it's extremely contentious, and only a very little bit is relevant. Also pushing Maven doesn't help me explain why we need dependency injection. Overall this answer doesn't help me sell Dependency Injection, just tells me a lot of things I need to do for my build process.
    – C. Ross
    Dec 12, 2012 at 13:47
  • 2
    Dependency Injection (the design pattern) is not Dependency Management (the build pattern). You have already covered all the most important aspects in your question. If your team still need convincing after hearing those, then seeing what Dependency Management will lead to should be the final convincer.
    – Gary
    Dec 16, 2012 at 20:02

And the #1 item on our top 10 list is ...

(drum roll)

Every developer builds with exactly the same versions of all the dependencies, so you never have to wonder what to deploy into production.

  • 2
    How is that any different than checking in the dependencies? In fact if you don't check in the dependencies you run the risk some 3rd party breaking your distro. I've had this happen more than once where some bower dep points to a repo someone deleted or renamed. If I had just copied the source into our repo that problem goes away.
    – gman
    Nov 25, 2014 at 7:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.