<< Sick sick sick | Main | More shit I can do without >>

Is dependency management useful for internal projects?

chris on 2008-Jan-19 11:56 PM

One of the benefits of Maven is that you can declare your project's dependent libraries and they'll be pulled down from a central repository for you. And if they're configured properly, maven will also pull their dependencies as well. Sounds great, and an entirely separate project (Ivy) also exists in the Apache world to do this within Ant.

But how useful is dependency management for internal projects? It is (or better be!) the goal of any build process that every checkout of the same code should build the same way every time. But I think introducing a dynamic layer (dependency resolution) into the compilation process subverts that goal. Those dependency mappings are under the control of other folks who can get things wrong. The open source community being what it is they'll probably get corrected sooner or later. But you don't know when. (You can correct it yourself: see discussion of repositories below.)

And then there's the 'SNAPSHOT' issue. A project can declare a dependency on a library's development version. Most of the time it's something like 'foo-2.0-SNAPSHOT.jar' with no idea as to when the snapshot was taken. So when the snapshot is updated (e.g., someone thinks to update the public repository) you'll get a different snapshot than what was initially used. Most of the time it will likely not be an issue, since hopefully not much changes between SNAPSHOT releases. But 'most of the time' shouldn't be good enough with something like builds.

Typically you'll only checkout from a past label to fix a bug. To fix a bug you need everything to remain the same except your fix, otherewise there's always the chance that you'll introduce side-effects which may become immediately apparent, or they may lie in waiting until some weird condition presents itself and then fail. (And hopefully not silently.)

Ah, wait, there's a way out. Since maven gets is dependencies via HTTP it's pretty simple to maintain your own maven repository that all the developers use. So you'll always have the same version of the '-SNAPSHOT' file. And you can fix any errors in the declared dependencies of your projects as well. True, true...

...but the original point of all this dependency management was so that I wouldn't have to manage anything. Now I have to maintain a local webserver, along with telling all the developers they'll have to make a configuration change to reference it? (Which goes against making the setup as easy as possible.) Feh, I say!

Let's walk through alternative, maintaining the dependencies yourself in your favorite version control system:

  1. I add a new library 'foo v 1.4.5' to my project by copying its JAR to my 'lib/' directory
  2. The docs declare that there are two dependent libraries, 'foo-utils v 1.4.5' and 'commons-blah v 2.3', I copy those to my 'lib/' directory, too.
  3. I add a note to my project's dependency manifest so someone can determine what libraries we're using and their licenses.

Since my Ant task for compiling my project pulls everything from my 'lib/' directory, I'm good to go.

When the 'foo' library gets upgraded I review its improvements and bugfixes and decide that we should upgrade. So I go through the same process as above, first removing the old versions then adding the new ones.

There is a complication when an upgrade no longer depends on a library, so without the metadata that 'commons-blah v 2.3' was only needed by 'foo v 1.4.5' I'll have an orphaned library in my classpath. And the harm in that is... the classloader has one more JAR to scan through.

There's also the potential issue that my own project (or a dependency) depends on 'commons-blah v 1.8', so the introduction of 'v 2.3' may introduce incompatibilities. But this is a general library issue and doesn't come from using (or not) dependency management.

In all cases:

  • The library files are included in every checkout, and the proper version of a library and its dependencies are associated with a release,
  • developers don't need extra configuration to build,
  • nor do they need a connection to the net.

So how is dependency management helping me out again?

Comments

No comments to display.

New comments are disabled.

... with proper design, the features come cheaply. This approach is arduous, but continues to succeed.
--Dennis Ritchie

Archives
4/2008 (2) 3/2008 (2) 2/2008 (4) 1/2008 (3) 12/2007 (2) 11/2007 (8) 10/2007 (3) 9/2007 (2) 8/2007 (8) 7/2007 (5) 6/2007 (19) 5/2007 (4) 4/2007 (2) 2/2007 (4) 1/2007 (4) 12/2006 (8) 11/2006 (7) 10/2006 (11) 9/2006 (6) 8/2006 (2) 7/2006 (3) 6/2006 (14) 5/2006 (1) 4/2006 (5) 3/2006 (12) 2/2006 (14) 1/2006 (18) 12/2005 (12) 11/2005 (10) 10/2005 (9) 9/2005 (3) 8/2005 (6) 7/2005 (18) 6/2005 (12) 4/2005 (6) 3/2005 (21) 2/2005 (13) 1/2005 (12) 12/2004 (14) 11/2004 (23) 10/2004 (23) 9/2004 (22) 8/2004 (7) 7/2004 (12) 6/2004 (23) 5/2004 (29) 4/2004 (24) 3/2004 (34) 2/2004 (21) 1/2004 (31) 12/2003 (16) 11/2003 (37) 10/2003 (32) 9/2003 (24) 8/2003 (21) 7/2003 (29) 6/2003 (27) 5/2003 (27) 4/2003 (26) 3/2003 (41) 2/2003 (29) 1/2003 (38) 12/2002 (46) 11/2002 (41) 10/2002 (45) 9/2002 (99) 8/2002 (111) 7/2002 (7) 6/2002 (19) 5/2002 (18) 4/2002 (7) 3/2002 (8) 2/2002 (22) 1/2002 (13) 12/2001 (4) 11/2001 (5) 10/2001 (5) 9/2001 (6) 8/2001 (6) 7/2001 (5) 6/2001 (5) 5/2001 (4) 4/2001 (4) 3/2001 (3) 2/2001 (6) 1/2001 (3) 12/2000 (1) 11/2000 (2) 10/2000 (7) 9/2000 (7) 8/2000 (6) 7/2000 (13) 6/2000 (6) 5/2000 (2) 4/2000 (3) 3/2000 (8) 2/2000 (4) 1/2000 (4)

All Tags
ada advertising aging aimeeman airlines ajax alcohol animals annoyances ant apache api astronomy attention baby badsoftware barackobama beauty bicycle bicycling birthday biz blog blogging books brain broadband browser build bureaucracy california cars cartoons cats charity chores classifieds clothes clown codegeneration coffee collaboration comics commercials communication community conference config corporate cpan css curmudgeon cwinters.com daily life dancing database datetime dating dc death debate design development distributed diy documentation dormont doublespeak driving dumb ebay ecommerce econ education ejb ella email embedded environment etech exercise expat family farming feed fiber fiction food fun furniture future gambling games geek gentoo geology gis government grammar greece groups gui hair hardware harrypotter hate health hiring history holiday house http ide identity illness imap ipod isp j2me jamming java javascript javaspaces jini job journalism kickass kids kinesis language lazy links linux lisp list lists living mac madison management map marriage maven media medical memory messaging meta military money movies moving ms150 music naked niagara nostalgia nyc oi2 opensource orm outsourcing parenting patent patterns pennsylvania perforce perl personal photography photos pinball pittsburgh planning politics postgres postgresql presentation privacy programming proliant proxy pseudoscience purity quiz quote race radio rant refactoring reflection relationship releases religion rest reunion review ricksantorum rules sandiego scatological science scm scripting security serendipity server servlet sex shell silly slang sleep soa soccer solaris specialization speech sports spring standards starwars steelers struts suburbs swing sysadmin tags team technology telecommuting terrorism testing thnkpad tradition transaction transportation travel traveling tutoring ui unix uptime usability usergroup vacation vc vocollect voice voting vpn walmart washingtondc weather web webservices wedding wiki win32 work writing xml yapc zeroconf