I'm sorry to be dragged again into this discussion. No, the man is the "judge", so far I could figure. In any case, the idea the comic was trying to convey was that if you measure by an inappropriate measurement tool, then the result will be random, or, as in that case, biased, because the tool was chosen specifically to favor one of the candidates.
And so it is with this debate: some argue for the change because they would benefit from it, and put their benefit as the reason to justify the change. What I'm saying is that so far there are also disadvantages that come with the change, I'll not favor it, especially since I'll gain absolutely nothing. Under disadvantages I count: - a viper nest of dependencies, which today may be handled by hand, but are under total control of the project owners. Once it goes by the Maven rules, you will have to adjust to whatever other repositories provide (that has been referred to earlier as "non standard version of package X" being used in the SDK code. Which is non-standard from the standpoint of whoever uses Maven repositories, but there's no real standard, and, in fact, if there were changes, they might have had a reason. But even if not, then the idea of denying oneself the ability to have a local patch in the future doesn't sound promising. - an extremely buggy and inflexible tool, which Maven build certainly is. (not the Maven itself, but the build written w/o an ability to debug it, while being limited to a very narrow spectrum of functions will certainly be buggy and inflexible). Maven cannot even do arithmetics on it's own. Neither it can print messages during the build, it has nothing to backup boolean logic, no abstraction of file system and many-many more limitations which will result in eventually adopting some other tool to compensate for disabilities. And so, while the build will be done mainly by Maven, it'll be plagued by shell scripts, and, almost certainly Ant droplets all over the place. - a tool difficult to install and use. All in comparison, but installing Ant is really easier, and the use is more straight-forward. Especially, in the light of the above - the build wouldn't only require Maven, it will, most certainly require Ant, but probably it won't stop there (as SDK builds in the past did make use of shell scripts). - Maven belongs exclusively to the Java "ecosystem", which means that very little code from other language, including AS3 can be obtained as a Maven artifact. Certain communities don't have any habit of using it, and will not likely switch to using it upon request. So, for instance, it's hard to imagine someone who's developing AS3+PHP, AS3+Python, AS3+.NET etc, who'd be happy to add a monumental complicated system to their project, while all they need is one or two SWCs. - Maven is a "selfish" way to go about building your projects. It's either you play by the rules, or you are out of the game. For instance, Maven artifacts require certain structure. As it was noted before, for example, they require that there be a MD5 checksum provided with the binaries. This may be OK for people who are used to it, but a complete majority of those writing in languages other then Java are unaware of such requirements. Eventually they may provide hashes, but not necessarily in the format that Maven expects it to be. So, back to my point. It may seem natural for someone that Maven should be used for everything, if "everything" to them is enterprise Java, and they are unaware of anything else. But enterprise Java is not enough of an authority to impose it's will on everyone else. Best. wvxvw
