#### Note: Most of the points listed below are very basic and are well known. They are listed below merely as a wiki in the hope to find some consensus.
* __IDE independence__
With the current Ant build, developer has to maintain both the ant build and the IDE build. A Fix for one doesn't mean fix for both.
We often checkin files unrelated to the actual code in the form of project files. So in addition to the code itself, the developers now need to checkout these project files and more often than not, they will have to tweak them for their own environment. Once they go through all the pain to customize these, they can't check them in or somebody else's environment might get messes up. So while they have to always take an update, they can never check them in.
Compare this with either Maven or gradle. IDE's just read the build scripts and generate the necessary project files, atleast the good ones anyway. Dev would then have to ignore these files in SCM, but that is a one time deal. And that's it, no more messing around with IDE's build system anymore. Whether you build on command line or in the IDE, the behaviour is exactly the same.
Devs wouldn't be constrained to one IDE, the build script would be the single source of truth and they would be free to use any IDE that supports the build script without needing to do a separate setup for that IDE or affecting anybody else's IDE setup.
* __Generic and predictable directory structure__
Convention over configuration is the term I heard people say. AFAIK, most modules in WLN are either jars or wars. Most modern build systems have a predefined directory structure that is based on
best practices. Where as with ant, structure is different in each project because there is no enforcement of conventions. Also, most of this is repetitive and one shouldn't have to either create it or maintain it repetitively. Build tools already do this and very well.
* __The argument against Ivy__
The one thing that seems to work for IVY IMO is it's capability to download dependencies from a network directory. Thomson already seems to have an in-house Nexus repo. I don't see why IVY makes sense anymore.
* __More expressive syntax vs arcane xml__
There are various options here.
- [Gradle](
http://www.gradle.org/) - [SBT](
http://www.scala-sbt.org/) - Maven with [tesla-polyglot](
https://github.com/takari/maven-polyglot) offers the capability of writing the build script in 5 different languages.
* __The pain of conversion__
FWIW, I was able to convert the two modules that I work on, from ant to gradle in about 4 hours time and was able to build both modules. Granted they might need more work to be compatible with CM's needs, but that still wouldn't increase the conversion time a whole lot. But this issue is subjective and depends on the specific tool. But I'd be surprised if any of them actually need more time to setup than Ant.
* __The freedom to do just about anything with ANT__
Well, just about anything might be an exaggeration. I agree Maven might not be well suited for this kind of a need, but gradle is a groovy DSL and is great for scripting and provides even more flexibility and language features than ant does.
* __Build times__
While there are many usual culprits that delay the build, I want to point out one thing that I haven't heard people mention, modularization. Apart from the many benefits modularization offers,
significant reduction of build times is one of the key ones. Most of us devs are working on a minor part of the code base at a time. Therefore we don't need to build all the classes that are part
of the module and run all the tests against them every single time. Well, may be this point is a streach, but IMO there is merit in this.
Because we the Nexus repo now, a new build scripting language, which would also be using the same Nexus repo, would not add to the build times due to delay in dependency resolution.
Imagine you point the IDE to a project directory and the project is automatically configured inside the IDE and the next step is to build the project and run. This is actually possible.
We wouldn't need these elaborate setup instructions for an IDE except may be a few lines of tomcat configuration which is inescapable. New devs go up and running on the first day.
Imagine when you look at the build script you get a tingly feeling in you heart, as opposed to perplexion and anxiety .
If you find inaccuracies, post the correction. If you disagree, please let me know why you disagree. If you agree, upvote and let your agreement be know. But all in all, this is a light hearted rant,
nothing offensive intended. Cheerios
__Reply to George__
Thankyou for the reply. But, everything you have attributed to Ant, maven and Gradle do it atleast five times better. You can build the project from command line, both Maven and Gradle enforce a project directory structure, this improves consistency allowing IDEs to work with them transparently.
Unfortunately I found that the opposite is true with IDE specific files. One should never checkin IDE files into SCM. Checking them in causes a lot of problems with keeping them in sync. Almost always people have to do customization to the Project settings to get it working in their local environment. When they do, they can't check them in because they might break somebody else's environment. So the dev has to add them to `ignore` file. Now they are stuck with merging these files every time they take an update, aagh.
Good IDE's like Netbeans take just the maven script as the single source of truth, they watch for the changes in the build script and automatically update the project. They provide repository explorers and one click addition of dependencies. Provide dependency graph viewers etc.
No two IDEs understand each others Ant scripts unless there are special project importers (which currrently exist for importing eclipse projects into Netbeans and IntelliJ but there are none for other IDE combinations). This constrains developers to use the IDE that understands these Ant scripts possibly reducing their efficiency because their dexterity is with some other IDE.
IMO, developers should be free to use the tools that they are most comfortable with as long as they deliver what is expected from them and as long as they are costing extra to the company, especially when the company's turnover rate is relatively high. I mean, think about it, how would a sitar player play sitar on a guitar
. Constraining them to specific tools for fixable reasons only reduces their productivity in turn reducing the company's productivity.
