[logback-dev] Running the logback project as a commitocracy

Joern Huxhorn jhuxhorn at googlemail.com
Mon Feb 21 15:29:25 CET 2011

On 21.02.2011, at 00:27, Craig P. Motlin wrote:

> Yes, they are both in-language DSLs. Gradle seems like a next-generation ant since it's very configurable. SBT seems like a next-generation maven since projects retain the maven directory layout and have standard lifecycle steps like compile and test.

Gradle is actually both.
It supports the same Maven lifecycle including the same directory structure by default but gives you the freedom to change everything if needed.
If a Maven project is moved over to Gradle this behavior is obviously left on default settings.

Gradle is much like Maven since it adheres to convention over configuration. But, on the other hand, it gives you the ability to change everything if necessary/desired. The ability to simply use Groovy code in tasks enables the same power that one had in Ant, but without reinventing the wheel in every new build file.

Use of Groovy code is the exception and is only necessary if the default behavior is not sufficient for a module-specific special case. Deleting the stub implementations in slf4j-api would be an example for such a case but I'm pretty sure that a simple exclude defined for the jar task of the slf4j-api module would be sufficient.

Steve Ebersole did a nice write-up about the reasons why Hibernate switched to Gradle:


More information about the logback-dev mailing list