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

[Joern Huxhorn]

On 19.02.2011, at 22:51, Ceki Gülcü wrote:

> On 19/02/2011 10:06 PM, Joern Huxhorn wrote:
>> 
>> On 18.02.2011, at 23:08, Ceki Gülcü wrote:
>> 
>>> Sure. I understand that seeing one's contributions ignored/declined
>>> can be frustrating. I am sorry for ignoring/declining the
>>> contributions which deserved better.
>>> 
> 
> 
> > For a more recent example I asked about switching to Gradle in
> > http://www.mail-archive.com/slf4j-dev@qos.ch/msg00487.html and got no
> > answer yet...
> >
> > I interpreted  this as a "no"  but I may  be mistaken and it  just got
> > lost on the mailinglist...
> >
> > How about setting up Gradle build for Logback and/or SLF4J? We could
> > leave the Maven2 build in place for a transition period, of course...
> 
> I am torn between Grovvy and Scala as replacements for Java.
> 
> Groovy is easy to learn, adds higher order functions and a whole bunch
> of other very nice features. However, it is not statically typed which
> means that Groovy code is much slower than Java (for CPU intensive
> code). Just as importantly, the Groovy compiler skips type checking
> which leaves you to discovering errors at runtime.
> 
> Scala on the other hand is as feature-rich as Groovy but statically
> typed.  Scala's type-inference mechanism is a source of continuous
> amazement. Given that it is statically typed, Scala generates code
> which runs as fast as Java. However, Scala is harder to learn than
> Groovy, at least it was for me. Scala also has extremely serious
> backwards compatibility issues due to the way traits are folded into
> code which import them.

That' reflects exactly my impression... :)

I'm not really fit in Scala yet but it's definitely very interesting and is very high on my "take a deep dive into it" list.

Groovy, on the other hand, is nearly able to compile Java code. The syntax can be very similar to Java (even though it's not really Groovy as a Groovy developer would write it in that case ;)), giving it a serious advantage in acceptance by Java developers.
That's not a personal opinion but a personal experience I made.
Most of my co-workers disliked Scala as soon as they saw "var foo : String".
Yes, it does make more sense to define variables like this - but it also turns off Java people the moment they see it, even before you get the chance to explain *why* it does make sense. A small thing like that can make a big difference in adoption rate... as silly as it may be...

The backwards compatibility issues is the main obstacle of Scala right now and is the reason why I haven't really bothered to use Scala for anything bigger than small examples yet.

Concerning speed and type-safety, I have quite high hopes for http://code.google.com/p/groovypptest/

> Both languages are DSL friendly. It is rather easy to write
> in-language DSLs in Groovy and Scala. In my experience, coding a DSL
> in Groovy is easier but Scala DSLs are type checked by the compiler
> which is a big plus (as you get IDE support, e.g. completion, for
> free).
> 
> As Scala is only used in tests, we could stop using Scala. (I've
> written a configuration DSL for logback in Scala. The syntax is
> similar to what we have in Groovy but the Scala version is
> type-checked.)
> 
> Anyway, can you describe what you like in Gradle?
> 

Concerning the build system, it's more or less a contest between XML & Groovy, not a contest between Groovy & Scala. ;)
Maven was a very nice improvement compared to Ant in that it enabled you to leave a lot of work to convention instead of manually specifying what needs to be done during build. But if you wanted to diverge from that convention it's a major PITA.
The fact that it's necessary to touch every single pom file during a release (you wrote a script to handle this IIRC) is just one of those pain points. I'm referring to those "Preparing release of..." and "Starting work on..." commit-messages...

With Gradle you get back a huge amount of freedom while leaving the rest to convention. An release, for example, would only require changing the version once at a single place, i.e. only a "Starting work on..." commit-message touching a single line in single file.

This is only the most obvious point. In Gradle, you can structure your build files any way you like.  Best practices are still in the process of being established in Gradle.

I choose the following layout for Lilith and Sulky:
https://github.com/huxi/lilith/blob/master/dependencyDefinitions.gradle contains the definition of all external dependencies and is comparable to the <dependencyManagement> section of a parent pom in what it provides.
https://github.com/huxi/lilith/blob/master/projectDependencies.gradle contains the definition of the dependencies of each sub-module. I'll probably rename that file into moduleDefinitions at some point.
https://github.com/huxi/lilith/blob/master/config.gradle contains everything else, i.e. everything in addition to what's provided by convention. It also contains some code to work around certain bugs or shortcomings of the current Gradle release. This is a rather complicated build, including the manual creation of a Mac application. Nevertheless, the file has only about 630 lines. The parent pom of the same project alone has nearly twice the amount of lines...

One of the biggest advantages is that it's very easy to just add some code or even write an entire plugin. I once tried to write a Maven plugin but simply gave up at some point because it was neither documented enough nor easy...
I needed GPG signatures of artifacts and there wasn't any support for it in Gradle, yet, so I wrote it myself and released that plugin.
I wanted to include the hash of the Git head in my application properties so I wrote another very simple plugin to support this, too. (See https://github.com/huxi/lilith/blob/master/GitHeadHash.gradle )
This is one of the really big advantages of Gradle. Extension is easy. Diverging from the given path will NOT kill you. There is no Grue lurking in a dark corner... :)

But there are many other advantages.
You don't have to do a "clean install" all the time to make sure that you are REALLY working with the latest changes in your code. Gradle will detect this and performs sophisticated up-to-date checks on its own. This is a killer-feature for really big projects.

I urge you to watch http://blogs.jfrog.org/2010/07/to-build-or-not-to-be-seminar-videos.html and/or http://vimeo.com/16571738 to see what Gradle is able to do... Those are really 2h worth spending...

At the moment, I'm keeping both Maven & Gradle build support in place for Lilith and Sulky but I do so only because Sonar does not support Gradle yet. The additional work required to keep both build processes up-to-date is negligibly (since Gradle is so nice to me).
While working on my projects, I only use Gradle for build since it's much faster and less error-prone.

Other big projects, like Hibernate and Spring, have also chosen to take the Gradle path. I'm pretty sure that Gradle is "the next big thing"...

I owe you a big one for getting me hooked on Git and this is my chance to give it back to you. The switch from Maven to Gradle was as important and relieving for me as the switch from SVN to Git... ;)

Cheers,
Joern.