The following is a comparison between MAVEN and ANT. I don't understand very much. Various large open source projects use Maven (apache, spring, hibernate, ibatis, etc.) Why is it worthless written here?
Where is the problem?
Java Build Tool Ant vs Maven writes
Nothing can satisfy all your thoughts unless you create one yourself. Also for the Build tool, maybe the best thing is to write it yourself. The build process for each project is unique, and often your project is built in multiple ways. It is basically unrealistic for the author of the Build tool to imagine the needs of each build to cater for it. The best tool is to provide a flexible library and reusable tasks that we can call on demand, but this is far from enough, and the finished tool will never meet your needs 100%. You'll waste a lot of time getting those tasks to work the way you want, but may end up having to write a plugin yourself. Writing your own custom build tools is quick and easy, and requires far less maintenance than you worry about. Build is about fitting your project and nothing else, so there's nothing to worry about.
If you don't want to write your own build tools, you can use Rake. Rake is currently the best Java project build tool based on the Ruby language. Rake provides a bunch of standard methods to accomplish common build tasks, and any other tasks can be done quickly with Ruby. Rake uses a real programming language (Ruby) to write build scripts, which is where it excels other tools. Of course, Rake has many other advantages, but none of them are as important.
Therefore, you should write your own build tools, or if you don't want to, use Rake. If you don't want to switch to Rake, you should also persuade them to switch to the right tool. If technical decisions are swayed by other things (office politics?), if you are not allowed to do that, then leave the project, nothing to say.
If you don't have the guts to quit, then use Ant. Ant is the second best build tool for Java projects. Although not as good as Rake, Ant is still arguably the most powerful build tool. Ant is mature and stable, fast and has a rich toolset. Ant allows you to express complex project building processes through well-fitted scripts, although not all of them are that simple.
All in all, write your own build tools, switch to Rake if you can't, fight for it if you don't, or resign to other places that let you use Rake. If that doesn't work at all, just use Ant and skip until someday a company uses Rake.
That's all, that's the only option I can suggest to you. Because you should never, ever, attempt to use Maven under any circumstances.
Maven's build itself is an endless cycle of despair that drags you bit by bit into the doomed Maven hell. It took you 10 minutes to set up the Maven environment at first, and you danced around. But with the progress of the project, your configuration needs to be increased, and the original pom.xml is definitely not enough. In order for the project to develop in the direction you want, you need to add configuration little by little. It won't be long before you hit the wall for the first time. (By the word "ghost hitting the wall", I mean "suddenly giving people a headache." I say "the first time" because you'll be hitting the wall again and again in the future). Finally, one day, you will make a temporary change to this messed up pom.xml in order to solve a pressing need. You might still be happy with Maven for a while...until another question shows a disgusting little head (which reminds me of a girl squeezing pimples on her face during puberty. When she squeezed the first pimple that appeared on her face Doudou, she will have a good sense of accomplishment. But when there are more and more peas, and they can't be squeezed cleanly, she no longer has any illusions about the white and flawless face of her teenage years-translator's note). This reminds me of the tragedy in Greek mythology where you are the soul cast into hell with an eternal curse - your Maven based build process.
Seriously, Maven is a terrible implementation of a bad idea. I believe there are always people who think Maven is smart enough, if not sexy, but in reality Maven's implementation shows no sign of that. In fact, Maven is downright terrible and has become a famous counter-example - telling people how not to build software. You know how horrible it is when the build is working the opposite way with Maven.
For example test results output from Maven's Surefire plugin. (The Surefire plugin is used to execute unit tests of an application during the test phase of the Maven build life cycle. It produces test results reports in two different forms: plain text; .xml files. By default, these files are generated in the project ${ The directory where the pom file is located}/target/surefire-reports directory. - Translator's Note). As long as the tests pass everything is fine, but if something goes wrong, Surefire's test reports are a debugging nightmare. Only the names of the failing test classes are logged. You must manually view the log files in the target/surefire-reports/ directory, which are organized by each test class. If multiple test classes fail, you must check multiple log files separately. It may seem like a small thing, but it can lead to a lot of resentment and reduced productivity.
Maven's claim of convention over configuration is a lie. The only conventions supported by Maven are: compile, run unit tests, generate jars. Do anything else and start configuring: generate a war package? To configure; run the program from the command line? To configure; run the acceptance test (list all the scenarios currently supported by the system in theory, and then classify the tests by function. If the test is successful, mark "success" in this scenario, otherwise, mark "failure". —— Translator's Note) or functional tests or performance tests, you still have to configure it, but it involves not being able to run your unit tests, or not running during the regular unit testing phase. Want to generate code coverage metrics for your project? You still have to configure, but your tests are run 2 times (or can be run only once, just not during the regular unit test phase); it will often report 0% code coverage despite doing full testing .
When it comes to configuration, Maven's configuration syntax is Sendmail (among users of Unix systems, Sendmail is the most widely used email server. Sendmail, as a free mail server software, has been widely used in various servers. It Excellent in terms of stability, portability, robustness, etc.) The most nauseating thing ever - alternating normal format XML. Therefore, Maven configuration is cumbersome, mouth-watering, and difficult to write. What can be done in 1 or 2 lines in Ruby, Rake's XML or Ant can be done in 6, 7 or 8 lines in pom.xml (and assuming that Maven can do it).
Maven's configuration is not at all coherent. One will refer to the relative path of the classpath, one will use the absolute path relative to the disk, and one will use the system properties of Maven running on the JVM. Some absolute paths can be ported because Maven knows how to automatically correct errors, and some cannot. Sometimes Maven is intelligent enough to know that if it builds the project recursively, sometimes it doesn't.
Also, some things are simply not configurable in the pom. For example: Maven repository, server, authorization credentials, etc. are configured in settings.xml. Since pom.xml is to be committed to the project's version control repository, it makes sense for Maven to place user passwords outside of the pom.xml file. But Maven's solution is horrible: all this configuration is put into a file called settings.xml, which is not in any project directory. You can't share any of these configurations directly between desktops and laptops, other developers, or your project's build server. However, it is automatically shared between every single Maven project you work on, and potentially every Maven project between different users on the same computer. When a new developer is added to the project, the necessary configuration information must be manually merged into the original settings.xml. When a new agent is added to the build server, it is still necessary to manually merge the necessary configuration information into the original settings.xml. Ditto when you migrate to a new machine. Any of these configurations need to be updated and must be updated manually on each individual machine. This is also a problem that was solved before Maven arrived: properties files. The project team submits the general property file to version control, and then each developer overwrites the information in the local property file, which is not submitted to version control.
All these things in Maven - those conventions, configurations, procedures - are managed in what is called Maven. Unfortunately, the so-called Maven way is undocumented. In order to capture that certain bit of fleeting information, it is often necessary to do a web search in the Maven documentation, Google it, or buy a book written by the Maven developers. (It's a bit like searching for her in the crowd for thousands of times, and suddenly looking back, I don't know where the spring will return - Translator's Note). There is another way to find the so-called Maven way is to beat the wall. (Walking and tripping over what I was looking for. The author meant that this - the so-called Maven way - is like an invisible border, and the way to try to find it may be to bump into it inadvertently - interpreter Note). Maven's builds are not designed to be flexible and do not support every possible build process. Maven is built for Apache projects, assuming that each project is built like an Apache project itself. This is great news for developers of open source libraries who volunteer their time, for whom "publish" means "upload a new zip file to your site for others to manually discover, download and add to them In my own project." In fact, this is the practice of slapping horses. Rake and Ant can adapt to every build process, Maven can't; Maven may, in fact likely, just don't support exactly the way you want to build software.
There's also the fact that Maven's dependency management is completely and irreparably broken. In fact, I take my word back; Maven's download of ibiblio (Maven will sync artifacts from a public repository at ibiblio.org, which is slow, unstable, and doesn't contain the latest version of some artifacts, and can't be uploaded privately to the team components. - Translator's Note) to the user's home directory, and then dump everything on the classpath like rubbish. This incredibly stupid dependency management strategy is horribly wrong and should never be confused with "dependency management". A Maven project I was working on recently produced a .war file of 51MB; when I moved it to Ant to manually configure dependency management, the .war file was reduced to 17MB. Come on, 51-17=34=17x2, actually two-thirds of the things are useless waste made by Maven for us.
Irrelevant dependencies not only eat up hard disk space, but also valuable memory. Maven is completely a big stupid pig that eats more and occupies more memory. Relatively simple projects, with just a parent pom and a few submodules, require a lot of JVM memory - obtained by changing the JAVA_OPTS configuration, which you usually only use on production servers. Things can be even worse if you integrate the Maven build tools into your IDE. It sets the JVM's maximum heap size to several hundred megabytes, sets the maximum PermGen size to several hundred megabytes, and enables permgen sweeping so that the classes themselves are garbage collected. (PermGen - Permanent Generation space refers to the permanent storage area of memory. This part is used to store the information of Class and Meta. Class is put into the PermGen area when it is loaded. It is different from the Heap area where Instance is stored. GC (Garbage Collection) will not clean up PermGen during the runtime of the main program, so if your APP loads a lot of Classes, a PermGen error may occur. - Translator's Note). All this is just building your project, or working with Maven in the IDE.
Funny story: in that project above, I once went through a 10 minute "mvn clean" build command because Maven stupidly wanted to do something before "rm -rf ./target/" (see a similar example : http://gist.github.com/267553). Actually the story isn't funny at all; trust me, you don't want a tool that automatically downloads all unresolved dependencies before emptying your build output directory. You don't want a tool - it automatically downloads all unresolved dependencies. Downloading all unresolved dependencies every once in a while makes your build process uncertain. Well, I'm an indeterminist: it's fun at school, not at work.
All that unnecessary, unwanted network back and forth takes up a lot of time. You pay the performance price for Maven's destructive package dependency management on every build. A 10 minute clean build is horrific, but a few more minutes per build is worse. My estimate of the average extra time per build is about one minute, based on the fact that I moved my Maven project to Ant and the average build time was reduced by 2.5 minutes to 1.5 minutes; similarly migrating an Ant project to Maven , the average build time increased by 2~3 minutes.
You have no control and can't see which packages are specified by which packages. Builds may break because different Maven versions download different packages at different times. Your local build will break one day too, when your dependencies accidentally release new, backwards-incompatible changes and forget to type the version number; those failures are innocent. It is more likely that your project A depends on a certain version of other project B, and this project B in turn depends on a final version of another project C, then you are still in the dark, even if the downstream package The provider typed the correct version number. Each release of a dependency package can create new bugs, thus wasting you hours tracking down why the build failed.
But Maven is even worse than that: Maven doesn't just resolve your project's package dependencies, it also automatically resolves the package dependencies of its own plugins. So now you don't just have to worry about different Maven instances accidentally downloading incompatible things (or the same Maven downloading different things at different times), you also have to worry about how your build tools behave at different times on different machines inconsistent.
Maven's broken package dependency management also poses a security risk, since it is currently impossible for Maven to determine where a package originally came from and whether it has been tampered with. When a package is uploaded to the code repository, the package is automatically digitally signed, and the signature is automatically verified when Maven downloads the package, but Maven undoubtedly trusts the signature in the code repository. Currently Maven's package security is controlled by Maven developers, who have write access to the ibiblio authoritative repository. But there is no way to know whether the code repositories of all dependent packages of the package you downloaded are poisoned, there is no way to know whether your local repository cache is poisoned, and there is no way to know where the packages in your local repository cache come from and who uploaded them.
In conclusion, the problem is not caused by careless programmers, nor can it be solved by the repository manager locking every package that Maven needs. Maven is broken and wrong if it assumes that people never make mistakes. If Maven wants the user to explicitly specify the version of each dependency, the dependencies of each dependency, to reduce the possibility of downloading incompatible packages, then it's a piece of junk. What if Maven had to go through a 3rd party tool to stop it from connecting to the network and automatically download those messed up dogs? Shit, then it's a piece of junk. Maven is a piece of junk if it ignores the need to connect to the network for every build, check every dependency for any update, and then download them automatically, making the build process unbearably slow. If Maven behaves inconsistently on my laptop at the office and at home, it's a piece of junk. If Maven needs the internet to even delete a directory, it's a piece of junk. Maven is a piece of junk.
http://niuzk0411.blogchina.com/1263375.html
If you don't want to write your own build tools, you can use Rake. Rake is currently the best Java project build tool based on the Ruby language. Rake provides a bunch of standard methods to accomplish common build tasks, and any other tasks can be done quickly with Ruby. Rake uses a real programming language (Ruby) to write build scripts, which is where it excels other tools. Of course, Rake has many other advantages, but none of them are as important.
Therefore, you should write your own build tools, or if you don't want to, use Rake. If you don't want to switch to Rake, you should also persuade them to switch to the right tool. If technical decisions are swayed by other things (office politics?), if you are not allowed to do that, then leave the project, nothing to say.
If you don't have the guts to quit, then use Ant. Ant is the second best build tool for Java projects. Although not as good as Rake, Ant is still arguably the most powerful build tool. Ant is mature and stable, fast and has a rich toolset. Ant allows you to express complex project building processes through well-fitted scripts, although not all of them are that simple.
All in all, write your own build tools, switch to Rake if you can't, fight for it if you don't, or resign to other places that let you use Rake. If that doesn't work at all, just use Ant and skip until someday a company uses Rake.
That's all, that's the only option I can suggest to you. Because you should never, ever, attempt to use Maven under any circumstances.
Maven's build itself is an endless cycle of despair that drags you bit by bit into the doomed Maven hell. It took you 10 minutes to set up the Maven environment at first, and you danced around. But with the progress of the project, your configuration needs to be increased, and the original pom.xml is definitely not enough. In order for the project to develop in the direction you want, you need to add configuration little by little. It won't be long before you hit the wall for the first time. (By the word "ghost hitting the wall", I mean "suddenly giving people a headache." I say "the first time" because you'll be hitting the wall again and again in the future). Finally, one day, you will make a temporary change to this messed up pom.xml in order to solve a pressing need. You might still be happy with Maven for a while...until another question shows a disgusting little head (which reminds me of a girl squeezing pimples on her face during puberty. When she squeezed the first pimple that appeared on her face Doudou, she will have a good sense of accomplishment. But when there are more and more peas, and they can't be squeezed cleanly, she no longer has any illusions about the white and flawless face of her teenage years-translator's note). This reminds me of the tragedy in Greek mythology where you are the soul cast into hell with an eternal curse - your Maven based build process.
Seriously, Maven is a terrible implementation of a bad idea. I believe there are always people who think Maven is smart enough, if not sexy, but in reality Maven's implementation shows no sign of that. In fact, Maven is downright terrible and has become a famous counter-example - telling people how not to build software. You know how horrible it is when the build is working the opposite way with Maven.
For example test results output from Maven's Surefire plugin. (The Surefire plugin is used to execute unit tests of an application during the test phase of the Maven build life cycle. It produces test results reports in two different forms: plain text; .xml files. By default, these files are generated in the project ${ The directory where the pom file is located}/target/surefire-reports directory. - Translator's Note). As long as the tests pass everything is fine, but if something goes wrong, Surefire's test reports are a debugging nightmare. Only the names of the failing test classes are logged. You must manually view the log files in the target/surefire-reports/ directory, which are organized by each test class. If multiple test classes fail, you must check multiple log files separately. It may seem like a small thing, but it can lead to a lot of resentment and reduced productivity.
Maven's claim of convention over configuration is a lie. The only conventions supported by Maven are: compile, run unit tests, generate jars. Do anything else and start configuring: generate a war package? To configure; run the program from the command line? To configure; run the acceptance test (list all the scenarios currently supported by the system in theory, and then classify the tests by function. If the test is successful, mark "success" in this scenario, otherwise, mark "failure". —— Translator's Note) or functional tests or performance tests, you still have to configure it, but it involves not being able to run your unit tests, or not running during the regular unit testing phase. Want to generate code coverage metrics for your project? You still have to configure, but your tests are run 2 times (or can be run only once, just not during the regular unit test phase); it will often report 0% code coverage despite doing full testing .
When it comes to configuration, Maven's configuration syntax is Sendmail (among users of Unix systems, Sendmail is the most widely used email server. Sendmail, as a free mail server software, has been widely used in various servers. It Excellent in terms of stability, portability, robustness, etc.) The most nauseating thing ever - alternating normal format XML. Therefore, Maven configuration is cumbersome, mouth-watering, and difficult to write. What can be done in 1 or 2 lines in Ruby, Rake's XML or Ant can be done in 6, 7 or 8 lines in pom.xml (and assuming that Maven can do it).
Maven's configuration is not at all coherent. One will refer to the relative path of the classpath, one will use the absolute path relative to the disk, and one will use the system properties of Maven running on the JVM. Some absolute paths can be ported because Maven knows how to automatically correct errors, and some cannot. Sometimes Maven is intelligent enough to know that if it builds the project recursively, sometimes it doesn't.
Also, some things are simply not configurable in the pom. For example: Maven repository, server, authorization credentials, etc. are configured in settings.xml. Since pom.xml is to be committed to the project's version control repository, it makes sense for Maven to place user passwords outside of the pom.xml file. But Maven's solution is horrible: all this configuration is put into a file called settings.xml, which is not in any project directory. You can't share any of these configurations directly between desktops and laptops, other developers, or your project's build server. However, it is automatically shared between every single Maven project you work on, and potentially every Maven project between different users on the same computer. When a new developer is added to the project, the necessary configuration information must be manually merged into the original settings.xml. When a new agent is added to the build server, it is still necessary to manually merge the necessary configuration information into the original settings.xml. Ditto when you migrate to a new machine. Any of these configurations need to be updated and must be updated manually on each individual machine. This is also a problem that was solved before Maven arrived: properties files. The project team submits the general property file to version control, and then each developer overwrites the information in the local property file, which is not submitted to version control.
All these things in Maven - those conventions, configurations, procedures - are managed in what is called Maven. Unfortunately, the so-called Maven way is undocumented. In order to capture that certain bit of fleeting information, it is often necessary to do a web search in the Maven documentation, Google it, or buy a book written by the Maven developers. (It's a bit like searching for her in the crowd for thousands of times, and suddenly looking back, I don't know where the spring will return - Translator's Note). There is another way to find the so-called Maven way is to beat the wall. (Walking and tripping over what I was looking for. The author meant that this - the so-called Maven way - is like an invisible border, and the way to try to find it may be to bump into it inadvertently - interpreter Note). Maven's builds are not designed to be flexible and do not support every possible build process. Maven is built for Apache projects, assuming that each project is built like an Apache project itself. This is great news for developers of open source libraries who volunteer their time, for whom "publish" means "upload a new zip file to your site for others to manually discover, download and add to them In my own project." In fact, this is the practice of slapping horses. Rake and Ant can adapt to every build process, Maven can't; Maven may, in fact likely, just don't support exactly the way you want to build software.
There's also the fact that Maven's dependency management is completely and irreparably broken. In fact, I take my word back; Maven's download of ibiblio (Maven will sync artifacts from a public repository at ibiblio.org, which is slow, unstable, and doesn't contain the latest version of some artifacts, and can't be uploaded privately to the team components. - Translator's Note) to the user's home directory, and then dump everything on the classpath like rubbish. This incredibly stupid dependency management strategy is horribly wrong and should never be confused with "dependency management". A Maven project I was working on recently produced a .war file of 51MB; when I moved it to Ant to manually configure dependency management, the .war file was reduced to 17MB. Come on, 51-17=34=17x2, actually two-thirds of the things are useless waste made by Maven for us.
Irrelevant dependencies not only eat up hard disk space, but also valuable memory. Maven is completely a big stupid pig that eats more and occupies more memory. Relatively simple projects, with just a parent pom and a few submodules, require a lot of JVM memory - obtained by changing the JAVA_OPTS configuration, which you usually only use on production servers. Things can be even worse if you integrate the Maven build tools into your IDE. It sets the JVM's maximum heap size to several hundred megabytes, sets the maximum PermGen size to several hundred megabytes, and enables permgen sweeping so that the classes themselves are garbage collected. (PermGen - Permanent Generation space refers to the permanent storage area of memory. This part is used to store the information of Class and Meta. Class is put into the PermGen area when it is loaded. It is different from the Heap area where Instance is stored. GC (Garbage Collection) will not clean up PermGen during the runtime of the main program, so if your APP loads a lot of Classes, a PermGen error may occur. - Translator's Note). All this is just building your project, or working with Maven in the IDE.
Funny story: in that project above, I once went through a 10 minute "mvn clean" build command because Maven stupidly wanted to do something before "rm -rf ./target/" (see a similar example : http://gist.github.com/267553). Actually the story isn't funny at all; trust me, you don't want a tool that automatically downloads all unresolved dependencies before emptying your build output directory. You don't want a tool - it automatically downloads all unresolved dependencies. Downloading all unresolved dependencies every once in a while makes your build process uncertain. Well, I'm an indeterminist: it's fun at school, not at work.
All that unnecessary, unwanted network back and forth takes up a lot of time. You pay the performance price for Maven's destructive package dependency management on every build. A 10 minute clean build is horrific, but a few more minutes per build is worse. My estimate of the average extra time per build is about one minute, based on the fact that I moved my Maven project to Ant and the average build time was reduced by 2.5 minutes to 1.5 minutes; similarly migrating an Ant project to Maven , the average build time increased by 2~3 minutes.
You have no control and can't see which packages are specified by which packages. Builds may break because different Maven versions download different packages at different times. Your local build will break one day too, when your dependencies accidentally release new, backwards-incompatible changes and forget to type the version number; those failures are innocent. It is more likely that your project A depends on a certain version of other project B, and this project B in turn depends on a final version of another project C, then you are still in the dark, even if the downstream package The provider typed the correct version number. Each release of a dependency package can create new bugs, thus wasting you hours tracking down why the build failed.
But Maven is even worse than that: Maven doesn't just resolve your project's package dependencies, it also automatically resolves the package dependencies of its own plugins. So now you don't just have to worry about different Maven instances accidentally downloading incompatible things (or the same Maven downloading different things at different times), you also have to worry about how your build tools behave at different times on different machines inconsistent.
Maven's broken package dependency management also poses a security risk, since it is currently impossible for Maven to determine where a package originally came from and whether it has been tampered with. When a package is uploaded to the code repository, the package is automatically digitally signed, and the signature is automatically verified when Maven downloads the package, but Maven undoubtedly trusts the signature in the code repository. Currently Maven's package security is controlled by Maven developers, who have write access to the ibiblio authoritative repository. But there is no way to know whether the code repositories of all dependent packages of the package you downloaded are poisoned, there is no way to know whether your local repository cache is poisoned, and there is no way to know where the packages in your local repository cache come from and who uploaded them.
In conclusion, the problem is not caused by careless programmers, nor can it be solved by the repository manager locking every package that Maven needs. Maven is broken and wrong if it assumes that people never make mistakes. If Maven wants the user to explicitly specify the version of each dependency, the dependencies of each dependency, to reduce the possibility of downloading incompatible packages, then it's a piece of junk. What if Maven had to go through a 3rd party tool to stop it from connecting to the network and automatically download those messed up dogs? Shit, then it's a piece of junk. Maven is a piece of junk if it ignores the need to connect to the network for every build, check every dependency for any update, and then download them automatically, making the build process unbearably slow. If Maven behaves inconsistently on my laptop at the office and at home, it's a piece of junk. If Maven needs the internet to even delete a directory, it's a piece of junk. Maven is a piece of junk.
http://niuzk0411.blogchina.com/1263375.html