| Thank you for espousing the Maven opinion. I would take your argument a step further and explain that mvn fits into common development workflows much the same tr fits into the word-counting example. Mvn is composable. Let me illustrate what we do at work to explain. We use Jenkins as a build server and a hosted git repository. Every accepted pull request to mainline-dev is picked up by Jenkins, Jenkins runs mvn test on the commit, if the build passes, Jenkins integrates the change into mainline-stable, and Jenkins runs mvn deploy to get the latest build on a mainline-stable server. Setting up this workflow required little customization because mvn's output was well-defined and designed to be composed within other environments, and jenkins is one common place that understands it. So are the IDEs at your work. So is the next person to tweak the environment who can look at docs to figure out what's going on. It's no different than how sed knows how to interpret tr's text output. Does this workflow work for everyone and every language? No, not at all. Does mvn the tool work for everyone and every language? No. But I see it as an example how mvn, a build tool, fits into larger process and is a composable tool the author lauds. P.S. The biggest benefit for our shop is twofold: 1) Dependencies get resolved automatically in all environments. Unlike my last gig, developers run the same version of libraries as the prod machines do. 2) Developers run the same test cases locally as jenkins does. We've only had one build break. |