Start today by organizing Maven series.
How to answer this question depends on how you look at the problem. Most MAVEN users call maven a "build tool": A tool used to construct source code into a published component. Build engineers and project managers will say Maven is a more complex thing: a project management tool. So what's the difference? Building tools like Ant are only focused on preprocessing, compiling, packaging, testing, and distributing. A project management tool like Maven provides a superset of the functionality provided by the build tool. In addition to providing built functionality, MAVEN can generate reports, build Web sites, and help drive communication between team members.
The definition of a more formal Apache maven: MAVEN is a project management tool that contains a project object model, a set of standard collections, a Project life cycle (ProjectLifecycle), A dependency management system (Dependency Management Systems), and the logic used to run the plug-in (plugin) target (goal) defined in the life cycle phase (phase). When you use MAVEN, you use a well-defined project object model to describe your project, and Maven can apply crosscutting logic that comes from a set of shared (or custom) plug-ins.
Don't let Maven be a "project management" tool to scare you away from the facts. That's the biggest reason I've compiled a series of MAVEN blogs. I used to use MAVEN to manage my project's jar dependencies, and this series of blogs will go into every detail of Maven, especially how to manage multiple projects with MAVEN, and carefully control the life cycle of a project.
We've also used ant,ant as a project builder for many years, and the main differences between Ant and Maven are as follows:
Apache Ant
1,ant There is no formal agreement like a generic project directory structure, you must explicitly tell Ant where to find the source code and where to put the output. Over time, informal engagements have arisen, but they have not yet been modeled in the product.
2,ant is programmed, and you have to tell Ant exactly what to do and when to do it. You have to tell it to compile, then copy, and then compress.
3,ant There is no life cycle, you must define the dependencies between goals and objectives. You must manually attach a task sequence to each target.
Apache Maven
1,maven has a contract because you follow the Convention, and it already knows where your source code is. It puts bytes into target/classes and then generates a JAR file at Target.
The 2,maven is declarative. All you need to do is create a pom.xml file and put the source code in the default directory. Maven will help you with other things.
3,maven has a life cycle that is called when you run mvn install. This command tells Maven to perform a series of sequential steps until it reaches the life cycle you specify. One of the implications of traversing the life cycle journey is that Maven runs many of the default plug-in targets, which complete tasks like compiling and creating a JAR file.
Maven provides built-in intelligence for some general project tasks in the form of plugins. If you want to write a run unit test, all you need to do is write the test and put it in/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/ Content-zh/src/test/java, add a test range dependency for testng or JUnit, and then run MVN test. If you want to deploy a web app instead of a JAR, what you need to do is change your project type to war and then place your document root directory as/usr/local/hudson/hudson-home/jobs/ Maven-guide-zh-to-production/workspace/content-zh/src/main/webapp. Of course, you can do these things with Ant, but you will need to write these instructions from scratch. With Ant, you first need to determine where the JUnit jar file should be placed, then you need to create a classpath that contains the JUnit jar file, and then tell Ant where it should go to find the test source code, write a target to compile the test source code to bytecode, use June It to perform unit testing.
Without the support of technologies such as Antlibs and Lvy (even with these support technologies), Ant feels like a custom programmatic construct. A set of highly efficient and committed Maven POM in the project, with little XML compared to the Ant configuration file. Another advantage of MAVEN is that it relies on a wide range of common maven plugins. Everyone uses the Maven Surefire plugin to run unit tests, and if someone adds support for a new test framework, you can get new functionality simply by upgrading a specific plugin version in your project's POM.
The decision to use Maven or ant is not an either-or, Ant has its place in a complex build. If your current build contains some highly customized processes, or if you have written some Ant scripts to complete a clear process in a clear way, and this process does not fit the MAVEN standard, you can still use these scripts in Maven. As a Maven core plugin, Ant is still available. Custom plug-ins can be implemented with ant, and Maven projects can be configured to run ant scripts in the life cycle.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Compare maven and Ant
