tag:blogger.com,1999:blog-11485756.post6891137894808826861..comments2023-09-25T12:19:44.716+02:00Comments on Thomas Ferris Nicolaisen's blog: In reply to Java Build Tools: Ant vs MavenThomas Ferris Nicolaisen http://www.blogger.com/profile/17464665832399025601noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-11485756.post-37152349240948316242012-02-10T21:20:06.564+01:002012-02-10T21:20:06.564+01:00Hi Anonymous,
I've argued for pretty much al...Hi Anonymous, <br /><br />I've argued for pretty much all these points in this 3-part series: http://blog.tfnico.com/2009/04/reason-3-dont-build-everything-all-time.html<br /><br />In the end it's a subjective choice where each side has its plus'es and minuses. There are certainly contexts where maven isn't the right tool for the job, but the arguments all still stand in their own right.Thomas Ferris Nicolaisen https://www.blogger.com/profile/17464665832399025601noreply@blogger.comtag:blogger.com,1999:blog-11485756.post-18200552987034989772012-02-10T20:33:01.055+01:002012-02-10T20:33:01.055+01:00Where to start?
"and I just mavenized the wh...Where to start?<br /><br />"and I just mavenized the whole thing from Ant."<br /><br />why on Earth did you do that? <br /><br /><br />"but then you end up with all the dependencies in one libs blob,"<br /><br />exactly, far, far superior to a repos that is no longer under source control. <br /><br />"and you invent a big bunch of conventions for your project, which may or may not be more practical than Maven's conventions."<br /><br />Right, with about 99.999% of the time being MORE practical, and 0.001% of the time being LESS practical.<br /><br />"and Maven of course. I am now so addicted to proper dependency management "<br /><br />So, storing all the required jars in one directory (call it 'libs') and letting each module link to that jar (each having the version in the name), is this somehow not 'proper'? I would argue that it is:<br />1. easier to understand<br />2. easier to remove a jar and swap out with the source should debugging be required<br />3. does not require a plug-in that destroys the meticulously optimized incremental build logic of Eclipse.<br /><br />"I have seen, these home-made conventions have been unclear, impractical and poorly documented."<br /><br />Have a look at H2. It has a nice built-in build tool. By using the Ant project logic (the recursive dependency 'topo sort') you can have a complete build tool without the baggage in about 2 days. This solution is clearer, more practical and requires less code and therefore less documentation<br /><br />"Yes, you need to have at least one Maven guru in your company to make it work for you"<br /><br />you must be joking. This statement is an admission of the complete failure of Maven. <br /><br />"As long as you have a Maven repository you trust, your build is entirely deterministic "<br /><br />Why would you trust a repository not under SCMS control?<br /><br />"well, having to exclude the transitive deps that you don't need is the price you pay for having automated transitive deps, which is a *great* feature in itself."<br /><br />automated transitive deps is a HORRIBLE feature, causing libs to be in the classpath of upstream modules that would not otherwise be explicitly included. They are not the default in NetBeans OR Eclipse (being bad design) as they introduce the possibility of coupling where before there was none (i.e., is this 'leaf' library required by an upstream module?), thereby decreasing modularity. The Eclipse Maven plugin includes all downstream jars, making projects that previously only required one or two libraries appear as if they required 10. This makes it more difficult to understand what a module does.<br /><br />Why Maven continues to have so many fanboys is a mystery.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11485756.post-17047973092105747112010-02-10T07:57:28.275+01:002010-02-10T07:57:28.275+01:00xpmatteo, since one of the early maven 2.0.x relea...xpmatteo, since one of the early maven 2.0.x releases, there have been default versions for the standard maven plugins in the super-pom. If you know which maven version is being used (usually standard for a company/team), you know which plugin versions were used. If you add new plugins and forget to define version, well, I share the opinion that this is a weakness in maven's design.Thomas Ferris Nicolaisen https://www.blogger.com/profile/17464665832399025601noreply@blogger.comtag:blogger.com,1999:blog-11485756.post-17657097331278807312010-02-09T18:22:09.608+01:002010-02-09T18:22:09.608+01:00Actually having a repository you trust is not enou...Actually having a repository you trust is not enough to make a Maven build deterministic. You also need to specify the version of every Maven plugin you happen to use, knowingly or not.xpmatteohttps://www.blogger.com/profile/16626755265235840659noreply@blogger.comtag:blogger.com,1999:blog-11485756.post-58925577758472385662010-01-05T16:38:10.427+01:002010-01-05T16:38:10.427+01:00Build tooling is one of the few areas where we are...Build tooling is one of the few areas where we are able to get reuse to work consistently. I am fairly certain creating a one-off build tool for my project doesn`t cause the world to become a better place.Unknownhttps://www.blogger.com/profile/04548343127231098433noreply@blogger.com