Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plugins in Scala, I'm sure you could do it in Kotlin too)
currently I use sbt and as said they are okai to work with, but they are not great, else there would've been only one. ;)
Actually I like many things on sbt, but It has some clear downsides and it's not hard to figure them out.
Actually I would favor gradle from all of them however I started with sbt and I think I actually will stick with it a while, even if there are some downsides.
That's a very unconstructive post. Please be more specific about upsides and downsides rather than just saying "It has some clear downsides and it's not hard to figure them out".
- slow resolution (could be really really really slow)
- transitive dependencies could be a mess since it could actually will mostly give you a evicition but it's hard to actually resolve that.
- however if you have two plugins a evicition is not printed, so you will actually get a funny stack trace if you actually use a library that resolve something via reflections. (i.e. closure compiler)
- sbt is slow
- sbt has some wierd operators.
- has problem with dynamic ranged versions
- scoped settings are cool, but could be wierd to understand, especially for new people
- sbt-web which tries to use npm which it packages as webjars which actually is a total mess since you actually run into the great world of npm packaging and try to force it into a completly different format.
there are more, however these are the ones I often deal with
I haven't used Stack enough to compare. The key points for Maven I think are: no arbitrary code in the build, strong adherence to conventions, extending that to the rest of the project lifecycle (e.g. the maven release plugin has a standard format for tags), immutable releases and consistent resolution.
You don't. If you need to run custom code in the build you have to encapsulate that as a plugin (which will be a first-class maven module in its own right, which naturally nudges you to writing unit tests, having a proper release process with semver and so on for your build step). But mostly you keep your build simple and declarative and you put any business logic in the actual code. It's wonderful.
You can use the maven polyglot plugin [1] to write your POM in something other than XML. It's fairly new, but it's there. We use it in JRuby to write our POMs in Ruby. As an example of a loop:
I don't know much about the development of the project, simply that it exists and is usable. I'd file an issue with the project and see what comes of it.
