4 ms·
As much as I love unix philosophy and tools that follow it, I would point out that using the build tool that comes with the language is usually the better optio
by drinchev 8y ago
As much as I love unix philosophy and tools that follow it, I would point out that using the build tool that comes with the language is usually the better option.
Nobody would use make instead of maven [1] with Java for example. Ruby uses Rakefile instead of Makefiles. You will probably confuse lots of developers
that work on your project if you do that.
On top of that Makefiles are known to be generated these days ( CMake ).
1 : https://stackoverflow.com/questions/2209827/why-is-no-one-using-make-for-java https://stackoverflow.com/questions/2209827/why-is-no-one-us...
- tomohawk 8y agoWho would use maven if they could use buildr? It's much faster and the build files are much easier to understand.
- kasperni 8y agohttps://www.jetbrains.com/research/devecosystem-2018/java/ https://www.jetbrains.com/research/devecosystem-2018/java/ Apparently, most people......
- doomhammer 8y agoI agree, notice that I use `make` together with `npm` as an example. Or with `setup.py`. Language build tools are great, but `make` comes in when you need to tie them together.
- chungy 8y agoMaven does not come with Java, and OpenJDK itself is built with Make rather than any other tool. The idea that "nobody" uses make for Java when Java itself does, is a little bit a stretch ;)
- charleslmunger 8y agoMaven is possibly one of the worst build systems I've used. It's an imperative build system with a declarative syntax; not parallel by default; always requires a clean build in practice, unless your code is all stuffed into one big blob. For a long time, it happily downloaded executable code from the internet without even basic cryptographic verification. Even the ergonomics of the tool are poor - it spams log output with all sorts of information other than what you actually need (like the output of a failed compilation). Getting information from a failed test is painful. If you change one module that another depends on, the latter will not be rebuilt - letting you find issues via NoSuchMethodError at runtime. Annotation processors require special care to enable, and don't always run when they should. I would rather use make and javac than Maven. Gradle, Bazel (and its diaspora of non-google imitations) would be much better choices.