three-cups

I first read SICP 10 years into my programming career. I felt like that was a good point to read the book. Any earlier and much of it would have been lost on me. But maybe this is the kind of book that you read and re-read and always find new things.

I guess I never found manual dependency resolution to be that big of a problem.

Fair point. But I'd say the dependency management in maven is actually more of a hassle than it's worth. For me, I understand jars in a lib directory well enough. Dependency management can become complicated pretty fast (e.g. version resolution).

It may be standard for Java, but I wouldn't say it's simple. I'll give you an example.

Say I want to use protobufs. There are a couple prerequisites: 1) I have to know the protobuf syntax. 2) I have to know how to compile the protobuf file into my language of choice.

If you're using maven, you also have to know which plugin to use (a simple google search), and add the 30 lines of XML to your build file. This is not such a big deal, except you're also hoping that the plugin supports all the protoc features that you may need. And what versions of protoc does the plugin work with? And is the plugin well documented?

Compare this to using make, or even using the <exec> ant task. protoc is well documented and you can access all the features you want in a standard way (command line options and arguments).

I would love to see more projects embrace this method of development as a lowest-common-denominator. I'd be great to be able to download a library and build it using the least number of tools. For a Java project, this might just be javac. The project could include build descriptors for ant, maven, etc. as well as IDE config.

It feels like half the time I download a Java/Maven project, there is some issue with the build that I have to spend time debugging. I'm not familiar with Maven, and Maven is pretty complicated, so this is a pain.