Ant, Maven, or others? The future of Java build tools

Not long ago, blog Adam bien wrote an article about the old topic ant or Maven, which wrote: "the real strength of Maven is its dependency management ), we have to do a lot of work to make ant dependency management reach the maven level ......" The article seems to have a preference for Maven, which aroused Adam pohorecki's debate and further discussed the future of Java build tools:

Although ant does not have built-in dependency management, it is very easy to integrate Ivy into your build. xml. So I think Adam bien's "a lot of work" is misleading.

If you want to select between ANT and Maven, I will select the former. I also understand why many people prefer Maven as their preferred build tool, because it has a build script that requires only a few lines of code to configure and has many features: dependency management, built-in compilation and packaging of application tasks, integration with jetty, a clean project web site, integration with cobertura, PMD or findbugs. In this case, Maven is a good choice if the project you start is very regular (using Spring & hibernate applications.

No one wants to write a build script because this code has no real commercial value. If you haven't encountered any problems, you will think Maven is really great. However, maybe your project is not conventional, maybe the plug-ins you use conflict with each other, and there are many failures in building systems such as Maven, and it is often difficult for you to find their source and fix them.

Ant has no obvious advantages over Maven. Moreover, ant has suffered from writing all the build code by hand. But once it is done, the build script truly becomes your code. In addition, when a problem occurs during running, you can check the code and modify it without having to trace like a headless fly.

But is Maven and ant just our choice? Are there any better options than them? Over the past few years, we have seen many projects that use tools that no longer use XML to define building logic, but real programming languages such as groovy, Ruby, and python, they often allow dependency management. Here are a few: gradle, Gant, Kundo, Raven, and buildr.

My favorite build tool is Gant, which has been released for just a few months. Gant is basically a groovy method that calls ant tasks and has many advantages over the old build. xml method. By using real programming languages rather than XML, many boring tasks in XML have become simple: extracting Common Code as methods, loops, and conditional logic. In fact, XML is neither a programming language nor should it be used as a programming language. Using languages like groovy or Ruby to build scripts is more concise and easy to understand, with less redundant code and clearer structure.

In my opinion, the future of building automation in the Java environment is gradle, or some other tools with similar features. Gradle is a kind of building script that I like: if it is a simple, standard project, you only need a few lines of configuration. It even allows transitive dependency management without using Maven or the ivy suite library ). When we first know "dependency management", we use Ivy. XML or pom. write down our dependencies in XML, and then have to install an independent repository (repository) to store these dependencies that cannot be found in the maven library, and have to fix pom. XML files, because some do not declare their dependencies. Now all of this can be history. We have DM, as long as we store the libs we need in the svn library, and then convert it to the real DM when it is used.

In addition, for large projects, gradle has the first-class support for multi-project building (for example, you can define project dependencies, when you build a subsidiary project, its Dependencies will also be built ). Gradle has many other features that you can search for in the User Guide on the official website, about 100 pages. I mean, if you are willing to spend some time reading, you will find that gradle will make your development much easier.

But I still have to admit that gradle may not be suitable for the "product concept". After all, project development is still a new thing. But if you want to find a better tool to replace ant, gradle is. If you want to find a tool to replace Maven, you may have to wait a few months, because gradle does not currently support the features that many Maven users depend on, such as the project URL, generating project documents for the main ides.

In summary, although there is no solution to all problems for automated building, new tools that are being developed are working hard to achieve this. It can be built either by convention or by the method you want. gradle attracts ant and Maven fans in both aspects. In my opinion, building scripts will be written in programming languages like groovy or Ruby in the future, and gradle will play a top priority in tools. Translated by Wang yulei)