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

Ceki Gülcü ceki at qos.ch
Mon Feb 21 16:49:31 CET 2011

On 21/02/2011 3:29 PM, Joern Huxhorn wrote:
> 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:
> http://community.jboss.org/wiki/Gradlewhy

Gradle's better/more flexible design is rather appealing. One of the 
fetaures I like about the current maven-based build is that IDEA can 
import it without any problems. Can Gradle projects be imported into 
IDEA as easily?

> Cheers,
> Joern.

More information about the logback-dev mailing list