Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
I think you've nailed it. –  Mike Partridge Nov 7 '12 at 14:31
    
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 '12 at 15:57
1  
@suslik Care to elaborate on what a "broken Maven" setup is? –  Andrew Finnell Nov 7 '12 at 21:33
    
I would guess a non stable release that you target in initial development with an intent to retarget mid-cycle to next stable... because of certain feature introduction in the non stable that was considered important; or an attempt to stay ahead of obsolescence. –  JustinC Nov 7 '12 at 23:36
    
@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 '12 at 15:02

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer
    
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 '12 at 13:47
    
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 Rowe Dec 16 '12 at 20:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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