The difference between Apache ANT and Apache Maven _ant

——— excerpt from the MAVEN Authority guide
Apache Ant
1. Ant is programmed, and you must explicitly tell ant what to do and when to do it. You have to tell it to compile, then copy, and then compress. 2. Ant has no lifecycle, you have to define the dependencies between goals and goals. You must manually attach a task sequence for each goal.
Apache Maven
1, Maven has the agreement, because you follow the agreement, it already knows your source code is where. It puts the bytes into target/classes and then generates a JAR file at Target. 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 lifecycle that is invoked when you run MVN install. This command tells Maven to perform a series of sequential steps until it reaches your specified lifecycle. One of the effects of traversing the lifecycle journey is that Maven runs a number of default plug-in destinations that do work like compiling and creating a JAR file.

Maven provides built-in intelligence for some general project tasks in the form of plug-ins. If you want to write a unit test, all you have to do is write the test and put it in the/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/ Content-zh/src/test/java, add a test scope dependency for TestNG or JUnit, and then run MVN test.
If you want to deploy a Web application instead of a JAR, what you need to do is change your project type to war, and then put your document root directory into/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, and then you need to create a classpath that contains the JUnit jar file, and then tell Ant where it should find the test source code, write a target to compile the test source code for bytecode, and use June It to perform unit tests. Without the support of technologies such as Antlibs and Lvy (even with these support technologies), Ant feels like a custom programmatic build.
An efficient set of Maven POM in the project, with very little XML relative to Ant's configuration file.
Another advantage of MAVEN is that it relies on a wide range of common Maven plug-ins. Everyone uses the Maven Surefire plug-in to run unit tests, and if someone adds support for the new test framework, you can get new functionality simply by upgrading the version of a particular plug-in in your project's POM.
The decision to use Maven or ant is not either or not, and Ant has its place in the complex build. If your current build contains a highly customizable process, or you've written some Ant scripts to complete a clear process in a clear way that doesn't fit the MAVEN criteria, you can still use these scripts in Maven. As a core plug-in for Maven, Ant is still available. Custom Plug-ins can be implemented with ant, and the Maven project can be configured to run ant scripts during the life cycle.