Ant + Ivy VS Maven: let's live together
In this article I will not develop another holivar on the topic that is steeper. Rather, a comparative review will be conducted based on the point of view of Apache itself and the personal experience of our Build Factory team. I draw your attention that this is a big Enterprise. This means that the accounting cases are not taken into account when they decided yesterday that today they should be done. But in the account taken very large project sizes, distributed throughout the world, development teams and other delights.
You can often hear the opinion that Ant itself cannot be compared with Maven. But Ant + Ivy can already compete with Maven. This is partly true.
* I wrote this, for I remember, somewhere Apache themselves said that the time had come for Maven, try to move away from Ant. But he could not find what he was looking for.
Alas, we all know that in most companies / projects the developers themselves deal with such an aspect as Build Management. Therefore, the opinion of developers on this topic on the Internet dominates. I read many articles with a detailed analysis of all the pros and cons of using both systems, and it became sad. The main goal of these articles was to compile the code. Well, sometimes even make an archive, installation, and fill it all somewhere on ftp or zadeloit Tomcat. Convenient dependency management, of course, is a very convenient feature, because it is taken into account. And that's all. And then Ant + Ivy start comparing with Maven.
For many, it will probably come as a surprise that, in addition to DEV and QA, there are TL, PM, PO, PSO, Support, CPE, L10N, Installation, designers, and many other places where the content comes from, which should also become part of the distribution package of the product. Based on this discovery, it becomes clear that leaving DEV does not have power over the process ... effectively. Therefore, in large projects there are separate Build Factory teams. But this is a topic for a completely different story.
Returning to our topic, we came to the most important thesis of this article. Ant is just the Build Tool, Maven is the Project Management Tool .
Well, now, starting from this thesis, we will compare the two systems in a completely different way.
I have often seen people trying to learn how to use Maven, using Ant as an example. Those. show how to do things that everyone used to do Ant'om, in Maven. And this is shown by comparing build.xml and pom.xml as an example.
But comparing these two files is fundamentally wrong.
Wiki:
In other words, in build.xml we describe our targets, consistently announcing other targets, which is very similar to the consistent execution of commands. The process of writing build.xml is nothing like writing a build script. We combine some targets into others, which creates a semblance of a function call, though not explicitly, but through a hierarchy of dependencies. We completely design the whole assembly process.
In pom.xml we do not have such freedom. In fact, Maven already knows what to do with your project, if this project has the appropriate structure. In pom.xml, we simply describe the project - this is the information implemented in XML. And for the successful use of Maven, it turns out, we need to understand all these lifecycles, phases and other things. We need to learn what Maven requires of us and how it works, and describe our project in pom.xml. This is usually the problem. Usually in DEV teams such a “restriction of freedom” is perceived extremely negatively. Instead of having to design your feature, you have to delve into how someone else’s code works, drive itself into the framework of these limitations, and so on. What for?
Well, firstly, the restriction of freedom in itself is not so bad. Developing this topic, we can slide to the holivar Assembler VS Java, but we will not do that. We just recall how often we see the .classpath and IDE files in the SCM. How difficult it is sometimes to understand this tangle of build.xml, how difficult it is to debug. How hard it is to understand which module is assembled before, and why this jar did not get into war. And when only the weights weigh ~ 3Gb, we will spend our man-hours on optimizing the build process. We will also spend them on design solutions when our managers come up with a new integration with another product, when they change the principles of localization or delivery of service packs. In general, a lot of headaches.
Now try to take what Maven imposes on us, not as a restriction of freedom, but as a kind of standardization. Take a look around, using Maven, we can integrate into the CI System, into the SCM, into the Issue tracker, Backlog, metrics, and anywhere. We can make a product release with one button. After all, all this was made possible thanks to this standardization (of course, it is possible to do this with Ant, but at what cost?). And the process of optimizing the assembly process is now in 90% of cases - a division of one module into several smaller ones that can be assembled in parallel. Integration with other participants of the development process was also noticeably simplified and became transparent - each team can have its own Maven repository (or one common corporate one), and we only change the versions of artifacts in pom.xml by the decision of top managers.
')
Why, then, you ask, still talk so much about Ant? As I said in the title of the article - let's live together. Let's just be aware that Ant and Maven are, above all, completely different tools. If you have a simple small project and do not have a strong Project Management, you can surely do without Maven. Especially if you are not familiar with it - because you have to spend time studying. In addition, large monstrous products, as a rule, are very slow and cumbersome. It is for this reason that many of them still use Ant. Perhaps managers do not see the need to migrate to Maven, and perhaps this is a legacy product (or its version) that is simply supported, and no more. Because Ant will be in demand and will not go anywhere. But if you already know how to use Maven, use it. This will help you in the future not to get on the rake. Still, Java and Ant are basically the same generation, and Maven was created much later - incorporating all the accumulated experience of the past years.
Useful links:
Ivy compares itself to Maven: ant.apache.org/ivy/m2comparison.html
Comparison from codehaus: docs.codehaus.org/display/MAVEN/Feature+Comparisons
Another interesting point of view: xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html
You can often hear the opinion that Ant itself cannot be compared with Maven. But Ant + Ivy can already compete with Maven. This is partly true.
* I wrote this, for I remember, somewhere Apache themselves said that the time had come for Maven, try to move away from Ant. But he could not find what he was looking for.
Alas, we all know that in most companies / projects the developers themselves deal with such an aspect as Build Management. Therefore, the opinion of developers on this topic on the Internet dominates. I read many articles with a detailed analysis of all the pros and cons of using both systems, and it became sad. The main goal of these articles was to compile the code. Well, sometimes even make an archive, installation, and fill it all somewhere on ftp or zadeloit Tomcat. Convenient dependency management, of course, is a very convenient feature, because it is taken into account. And that's all. And then Ant + Ivy start comparing with Maven.
For many, it will probably come as a surprise that, in addition to DEV and QA, there are TL, PM, PO, PSO, Support, CPE, L10N, Installation, designers, and many other places where the content comes from, which should also become part of the distribution package of the product. Based on this discovery, it becomes clear that leaving DEV does not have power over the process ... effectively. Therefore, in large projects there are separate Build Factory teams. But this is a topic for a completely different story.
Returning to our topic, we came to the most important thesis of this article. Ant is just the Build Tool, Maven is the Project Management Tool .
Well, now, starting from this thesis, we will compare the two systems in a completely different way.
I have often seen people trying to learn how to use Maven, using Ant as an example. Those. show how to do things that everyone used to do Ant'om, in Maven. And this is shown by comparing build.xml and pom.xml as an example.
But comparing these two files is fundamentally wrong.
Wiki:
Maven, unlike the other Apache Ant project builder, provides a declarative rather than an imperative build of the project.
In other words, in build.xml we describe our targets, consistently announcing other targets, which is very similar to the consistent execution of commands. The process of writing build.xml is nothing like writing a build script. We combine some targets into others, which creates a semblance of a function call, though not explicitly, but through a hierarchy of dependencies. We completely design the whole assembly process.
In pom.xml we do not have such freedom. In fact, Maven already knows what to do with your project, if this project has the appropriate structure. In pom.xml, we simply describe the project - this is the information implemented in XML. And for the successful use of Maven, it turns out, we need to understand all these lifecycles, phases and other things. We need to learn what Maven requires of us and how it works, and describe our project in pom.xml. This is usually the problem. Usually in DEV teams such a “restriction of freedom” is perceived extremely negatively. Instead of having to design your feature, you have to delve into how someone else’s code works, drive itself into the framework of these limitations, and so on. What for?
Well, firstly, the restriction of freedom in itself is not so bad. Developing this topic, we can slide to the holivar Assembler VS Java, but we will not do that. We just recall how often we see the .classpath and IDE files in the SCM. How difficult it is sometimes to understand this tangle of build.xml, how difficult it is to debug. How hard it is to understand which module is assembled before, and why this jar did not get into war. And when only the weights weigh ~ 3Gb, we will spend our man-hours on optimizing the build process. We will also spend them on design solutions when our managers come up with a new integration with another product, when they change the principles of localization or delivery of service packs. In general, a lot of headaches.
Now try to take what Maven imposes on us, not as a restriction of freedom, but as a kind of standardization. Take a look around, using Maven, we can integrate into the CI System, into the SCM, into the Issue tracker, Backlog, metrics, and anywhere. We can make a product release with one button. After all, all this was made possible thanks to this standardization (of course, it is possible to do this with Ant, but at what cost?). And the process of optimizing the assembly process is now in 90% of cases - a division of one module into several smaller ones that can be assembled in parallel. Integration with other participants of the development process was also noticeably simplified and became transparent - each team can have its own Maven repository (or one common corporate one), and we only change the versions of artifacts in pom.xml by the decision of top managers.
')
Why, then, you ask, still talk so much about Ant? As I said in the title of the article - let's live together. Let's just be aware that Ant and Maven are, above all, completely different tools. If you have a simple small project and do not have a strong Project Management, you can surely do without Maven. Especially if you are not familiar with it - because you have to spend time studying. In addition, large monstrous products, as a rule, are very slow and cumbersome. It is for this reason that many of them still use Ant. Perhaps managers do not see the need to migrate to Maven, and perhaps this is a legacy product (or its version) that is simply supported, and no more. Because Ant will be in demand and will not go anywhere. But if you already know how to use Maven, use it. This will help you in the future not to get on the rake. Still, Java and Ant are basically the same generation, and Maven was created much later - incorporating all the accumulated experience of the past years.
Useful links:
Ivy compares itself to Maven: ant.apache.org/ivy/m2comparison.html
Comparison from codehaus: docs.codehaus.org/display/MAVEN/Feature+Comparisons
Another interesting point of view: xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html
Source: https://habr.com/ru/post/174721/
All Articles