Maven by Example 1.3. A Common Interface
2014-12-22 09:31
246 查看
Before Maven provided a common interface for building software, every single project had someone dedicated to managing a fully customized build system. Developers had to take time away from developing software to learn about the idiosyncrasies(个性,[心理] 特异品质)
of each new project they wanted to contribute to. In 2001, you’d have a completely different approach to building a project like
Turbine than you would to building aproject like
Tomcat. If a new source code analysis tool came out that would perform static analysis on sourcecode, or if someone developed a new unit testing framework, everybody would have to drop what they were doing and figure out how to fit it into each project’s
custom build environment. How do you run unit tests? There were a thousand different answers. This environment was characterized by a thousand endless arguments about tools and build procedures. The age before Maven was an age of inefficiency, the ageof the
"Build Engineer".
Today, most open source developers have used or are currently using Maven to manage new software projects. This transition is less about developers moving from one build tool to another and more about developers starting to adopt a common interface for project
builds. As software systems have become more modular, build systems have becomemore complex, and the number of projects has sky-rocketed. Before Maven, when you wanted to check out a project like
Apache ActiveMQ or
Apache ServiceMix from Subversion and build it from source, you really had to set aside about an hour to figure out the build system for each particular project. What does the project need to build? What libraries do I need to download? Where doI put them?
What goals can I execute in the build? In the best case,it took a few minutes to figure out a new project’s build, and in the worst cases (like the old Servlet API implementation in the Jakarta Project), a project’s build was so difficult it would take multiple
hours just to get to the point where a new contributor could edit source and compile the project. These days, you check it out from source, and you run
While Maven provides an array of benefits including dependency management and reuse of common build logic through plugins, the core reason why it has succeeded is that it has defined a common interface for building software. When you see that a project like
Apache ActiveMQ uses Maven, you can assume that you’ll be able to check it out from source and build it with
of each new project they wanted to contribute to. In 2001, you’d have a completely different approach to building a project like
Turbine than you would to building aproject like
Tomcat. If a new source code analysis tool came out that would perform static analysis on sourcecode, or if someone developed a new unit testing framework, everybody would have to drop what they were doing and figure out how to fit it into each project’s
custom build environment. How do you run unit tests? There were a thousand different answers. This environment was characterized by a thousand endless arguments about tools and build procedures. The age before Maven was an age of inefficiency, the ageof the
"Build Engineer".
Today, most open source developers have used or are currently using Maven to manage new software projects. This transition is less about developers moving from one build tool to another and more about developers starting to adopt a common interface for project
builds. As software systems have become more modular, build systems have becomemore complex, and the number of projects has sky-rocketed. Before Maven, when you wanted to check out a project like
Apache ActiveMQ or
Apache ServiceMix from Subversion and build it from source, you really had to set aside about an hour to figure out the build system for each particular project. What does the project need to build? What libraries do I need to download? Where doI put them?
What goals can I execute in the build? In the best case,it took a few minutes to figure out a new project’s build, and in the worst cases (like the old Servlet API implementation in the Jakarta Project), a project’s build was so difficult it would take multiple
hours just to get to the point where a new contributor could edit source and compile the project. These days, you check it out from source, and you run
mvn install.
While Maven provides an array of benefits including dependency management and reuse of common build logic through plugins, the core reason why it has succeeded is that it has defined a common interface for building software. When you see that a project like
Apache ActiveMQ uses Maven, you can assume that you’ll be able to check it out from source and build it with
mvn installwithout much hassle. You know where the ignition(点火,点燃;着火,燃烧;点火开关,点火装置) keys goes,you know that the gas pedal is on the right-side, and the brake is onthe left.
相关文章推荐
- Maven by Example Chapter 2. Installing Maven
- Maven by Example 2.1. Verify your Java Installation
- Maven by Example 2.2. Downloading Maven
- Maven by Example
- Maven by Example 1.1. Maven… What is it?
- Maven by Example 3.5. Core Concepts
- Maven by Example 1.2. Convention Over Configuration
- Maven by Example 1.4. Universal Reuse through Maven Plugins
- Maven by Example 1.7. Comparing Maven with Ant
- Maven by Example 3.1. Introduction
- tomcat运行maven项目Caused by: java.lang.ClassNotFoundException:
- How to create a maven repository for your github project step by step
- Go by Example: Multiple Return Values
- ROS学习笔记(二)ROS by Example 学习笔记
- maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e.
- Spring 3 MVC Framework Based Hello World Web Application Example Using Maven, Eclipse IDE And Tomcat
- Go by Example: Hello World
- Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-plugin-plugi
- MyEclipse导入Maven项目报错 Plugin execution not covered by lifecycle configuration:
- Maven项目提示:Plugin execution not covered by lifecycle configuration