We seem to be caught in a build-quagmire. Should we put the build-tool decision up to a vote, or will we wait to see what people accomplish with the various build tools and then decide?
On Wed, Feb 29, 2012 at 4:45 PM, Left Right <olegsivo...@gmail.com> wrote: > 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 >
