3 ms·
Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible de
by koevet 13y ago
Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine.
Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle.
Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
- gaius 13y agoI looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
- koevet 13y agoWell, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be. A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
- IanCal 13y ago> Then carried on using Makefiles How do you deal with versioned dependencies with Makefiles?
- gaius 13y agoObviously the Makefiles gets branched with the err, branch. And merged with the merge.
- IanCal 13y agoI don't mean how do you version a Makefile, but if your project depends on 6 libraries (with various version requirements) each with their own sets of dependencies, how do you use Makefiles to download & install all of them?
- gaius 13y agoAh, I see. Well I don't get involved in projects as Rube Goldberg as that. The 3rd party libraries I rely on have stable interfaces, and current-version is always preferable.
- IanCal 13y agoOh right, then yeah Makefiles are the way to go :) I'm not sure I'd call those things Rube Goldberg, it's just about depending on small libraries and having a reproducible build if it gets checked out on a CI machine and run. As always, all about choosing the right tool for the job. If you can solve it cleanly with something simpler then you probably should. Something like Maven should only be used if you're really sure you actually need it, because otherwise it'll be a pain in the arse. Having said that, splitting up "building" and "dependency management" can make things much simpler. Pip (python dependency manager) is incredibly simple, with the same kind of interface as apt, and if you've got a file with a list of dependencies you just tell it to install all of those. Then you can use whatever you want for the build process itself.
- qznc 13y agoIt depends. For tracking released versions, just let the Makefile download (wget,tar) and build (./configure,$(MAKE)) it. For tracking repo revisions use the VCS (git-submodule,git-subtree).
- qwerta 13y agoAnt is essentially the same as makefiles.
- h_r 13y agoOr... it's more like makefiles with a lot of shell scripting sprinkled throughout.
- alextingle 13y agoSo... exactly like Makefiles, then.
- davidgerard 13y agoThe "this is code but you have to write it as correctly-formed XML" bit is whacky. OTOH, as syntax goes, it probably beats syntactically-significant varieties of whitespace.
- auvrw 13y ago> The "this is code but you have to write it as correctly-formed XML" bit is whacky. that's all over the java ecosystem, though, not just build tools: android and (i think?) spring both use several types of xml files to build. not saying it's not whacky, but it's def. prevalent.
- smrtinsert 13y agohavent had a problem ivy and ant didn't tackle relatively gracefully yet. I'm only using gradle because all the cool kids are but tbh I'm not really a fan of groovy. I wouldn't ever use the language outside of gradle and thats a bad sign to me.
- stephen 13y ago> but they decided to roll their own Ivy/Maven compatible dependency engine. I'd heard about that...as a non-Gradle Ivy user, when they started this, I asked two of their devs if they were going to basically write an "Ivy v2", submit their improvements/patches back to Ivy, etc. Their response was, paraphrased, "absolutely not, we're building our own thing that is way more awesome and are not interesting in sharing". Which I found disappointing. I know a clean break is easier, and that the Ivy codebase likely needs it, but Ivy could really have used their focus, and I think it would have benefited the wider Java ecosystem (as many non-Maven builds use Ivy to talk to Maven repos) instead of just Gradle itself.