Running the logback project as a commitocracy
Hello all, I am considering running the logback project as a commitocracy. The idea is to settle non controversial questions by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome. Developers earn one commit point per day for every day in which they commit code to the project. For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice. git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l At present time, the commit-points for the logback project: Ceki Gulcu 486 commit-points Sebastien Pennec 164 commit-points Tomasz Nurkiewicz 10 commit-points A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit). Your comments welcome. -- Ceki
Hi Ceki, On 14.02.2011, at 18:05, Ceki Gülcü wrote:
Hello all,
I am considering running the logback project as a commitocracy. The idea is to settle non controversial questions by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome.
Developers earn one commit point per day for every day in which they commit code to the project.
I'm not sure about the difference to the current mostly-BDFL way since only you will be the one that decides if a commit will actually enter the blessed repository at https://github.com/ceki/logback/ (or https://github.com/ceki/slf4j/ for that matter). I may be mistaken but I think not a single patch-submission by me has been applied without change in the past, even though I tried to work completely according to coding guidelines etc. Examples are http://bugzilla.slf4j.org/show_bug.cgi?id=112 and http://bugzilla.slf4j.org/show_bug.cgi?id=70 or my SLF4J proposal concerning VarArgs over at https://github.com/huxi/slf4j/tree/slf4j-redesign At the moment I could really use some support for Lilith concerning creation of both LoggerEvent and AccessEvent instances since I'd like to create those events myself to format them using Logback formatters. This isn't possible right now. See TODO in https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/l... and https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/l... I could obviously restart the old http://jira.qos.ch/browse/LBCLASSIC-45 about dumb, accessible data types for events instead of putting initialization logic into them and I could also just implement them all over again, with the very faint chance that my changes may actually be included. But I actually don't have too much hope anymore which, in turn, is seriously hampering my motivation to even try. I submitted a bug report nearly a year ago about this instead: http://jira.qos.ch/browse/LBACCESS-12 The most depressing thing so far was your comment at http://bugzilla.slf4j.org/show_bug.cgi?id=112#c5 since, in my opinion, we should *obviously* be better than the JDK. If the JDK fails to perform a sober toString(), exploding with a StackOverflowError, then I wouldn't exactly expect a logging framework to be able to tell me what is wrong but I would definitely be pleasantly surprised if it just was. The fix that you implemented in https://github.com/ceki/slf4j/commit/1d4547f0735b4f7bf185e5f39bb522da492855e... is actually just returning "[FAILED toString()]" instead of my suggested output "[!!!fully.qualified.ClassName@identityHashCodeInHex=>fully.qualified.Throwable:ThrowableMessage!!!]". The troublesome exception is essentially still eaten up. The fact that it is actually printed to the console doesn't really help, either. I'm using a logging framework so I don't have to scan the console output. My suggestion/implementation would have contained the information which class was the problematic one and also what, exactly, the actual problem was.
For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice.
git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
At present time, the commit-points for the logback project:
Ceki Gulcu 486 commit-points Sebastien Pennec 164 commit-points Tomasz Nurkiewicz 10 commit-points
The main problem with this heuristic is that even if I did a complete rewrite of the whole Logback project over a timeframe of two years and you'd just love it and decided to take all of my changes you'd still apply (merge) my changes on a single day giving me exactly one commit-point. Does not seem to be very fair to me. I think this does only work for non-distibuted repositories with multiple commiters but not for DVCS with a single blessed repository.
A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit).
I'm not sure if I really understand you correctly... Are you really suggesting to give up the blessed repository concept and add just about everyone as a Collaborator (as GitHub calls them)? I think the default GitHub way of working with pull-requests is a much better and safer way of work.
Your comments welcome.
I hope so ;) Sorry for ranting but I had to get all of this out of my system. Cheers, Joern.
Although the details are different, I've also pretty much given up being able to contribute anything to Logback. All my work now is focused on Log4j 2.0 even thought there is no guarantee it will ever be used by anyone. Committing changes to github on a branch no one is ever going to use and I have to constantly keep merging with your repo just seems pointless. It apparently also results in no points for me since none of it ever made it back into the official repo. As I'm sure you are aware I'm not a fan of the BDFL model so anything you do to loosen the reigns is welcome, especially if it means that Jira issues can be addressed and patches applied when you are on vacation. But FWIW, I knew how you chose to run the project when I first became involved so I'm not really too bent out of shape that my contributions weren't accepted. It just doesn't inspire me to devote a whole lot of time here. Ralph On Feb 14, 2011, at 4:45 PM, Joern Huxhorn wrote:
Hi Ceki,
On 14.02.2011, at 18:05, Ceki Gülcü wrote:
Hello all,
I am considering running the logback project as a commitocracy. The idea is to settle non controversial questions by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome.
Developers earn one commit point per day for every day in which they commit code to the project.
I'm not sure about the difference to the current mostly-BDFL way since only you will be the one that decides if a commit will actually enter the blessed repository at https://github.com/ceki/logback/ (or https://github.com/ceki/slf4j/ for that matter). I may be mistaken but I think not a single patch-submission by me has been applied without change in the past, even though I tried to work completely according to coding guidelines etc.
Examples are http://bugzilla.slf4j.org/show_bug.cgi?id=112 and http://bugzilla.slf4j.org/show_bug.cgi?id=70 or my SLF4J proposal concerning VarArgs over at https://github.com/huxi/slf4j/tree/slf4j-redesign
At the moment I could really use some support for Lilith concerning creation of both LoggerEvent and AccessEvent instances since I'd like to create those events myself to format them using Logback formatters. This isn't possible right now.
See TODO in https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/l... and https://github.com/huxi/lilith/blob/master/lilith/src/main/java/de/huxhorn/l...
I could obviously restart the old http://jira.qos.ch/browse/LBCLASSIC-45 about dumb, accessible data types for events instead of putting initialization logic into them and I could also just implement them all over again, with the very faint chance that my changes may actually be included. But I actually don't have too much hope anymore which, in turn, is seriously hampering my motivation to even try. I submitted a bug report nearly a year ago about this instead: http://jira.qos.ch/browse/LBACCESS-12
The most depressing thing so far was your comment at http://bugzilla.slf4j.org/show_bug.cgi?id=112#c5 since, in my opinion, we should *obviously* be better than the JDK. If the JDK fails to perform a sober toString(), exploding with a StackOverflowError, then I wouldn't exactly expect a logging framework to be able to tell me what is wrong but I would definitely be pleasantly surprised if it just was.
The fix that you implemented in https://github.com/ceki/slf4j/commit/1d4547f0735b4f7bf185e5f39bb522da492855e... is actually just returning "[FAILED toString()]" instead of my suggested output "[!!!fully.qualified.ClassName@identityHashCodeInHex=>fully.qualified.Throwable:ThrowableMessage!!!]". The troublesome exception is essentially still eaten up. The fact that it is actually printed to the console doesn't really help, either. I'm using a logging framework so I don't have to scan the console output. My suggestion/implementation would have contained the information which class was the problematic one and also what, exactly, the actual problem was.
For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice.
git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
At present time, the commit-points for the logback project:
Ceki Gulcu 486 commit-points Sebastien Pennec 164 commit-points Tomasz Nurkiewicz 10 commit-points
The main problem with this heuristic is that even if I did a complete rewrite of the whole Logback project over a timeframe of two years and you'd just love it and decided to take all of my changes you'd still apply (merge) my changes on a single day giving me exactly one commit-point. Does not seem to be very fair to me. I think this does only work for non-distibuted repositories with multiple commiters but not for DVCS with a single blessed repository.
A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit).
I'm not sure if I really understand you correctly... Are you really suggesting to give up the blessed repository concept and add just about everyone as a Collaborator (as GitHub calls them)? I think the default GitHub way of working with pull-requests is a much better and safer way of work.
Your comments welcome.
I hope so ;)
Sorry for ranting but I had to get all of this out of my system.
Cheers, Joern. _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
On 15/02/2011 1:45 AM, Joern Huxhorn wrote: [snip]
For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice.
git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
At present time, the commit-points for the logback project:
Ceki Gulcu 486 commit-points Sebastien Pennec 164 commit-points Tomasz Nurkiewicz 10 commit-points
The main problem with this heuristic is that even if I did a complete rewrite of the whole Logback project over a timeframe of two years and you'd just love it and decided to take all of my changes you'd still apply (merge) my changes on a single day giving me exactly one commit-point. Does not seem to be very fair to me.
What you describe would be very unfair. Fortunately, merging with git preserves the author and date. If a merge objectively deserves N commit points, the author of the contribution will get exxactly N points after the merge.
I think this does only work for non-distibuted repositories with multiple commiters but not for DVCS with a single blessed repository.
Nope, git merges conserve the original author and date.
A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit).
I'm not sure if I really understand you correctly...
Are you really suggesting to give up the blessed repository concept and add just about everyone as a Collaborator (as GitHub calls them)? I think the default GitHub way of working with pull-requests is a much better and safer way of work.
Commits can be reverted if proven to be unsuitable after review. Commitorctacy is designed to allow decision making in case a given commit is not unanimously approved.
Your comments welcome.
I hope so ;)
Sorry for ranting but I had to get all of this out of my system.
Sure. I understand that seeing one's contributions ignored/declined can be frustrating. I am sorry for ignoring/declining the contributions which deserved better.
Cheers, Joern.
-- Ceki
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... Cheers, Joern.
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. 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? -- Ceki
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.
On Feb 20, 2011, at 5:11 AM, Joern Huxhorn wrote:
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 very much doubt it. The big selling point for Maven is consistency - when you move from organization a to organization b (or even from project to project within a company) the same plugins still work the same way. From what I saw Gradle is a lot looser (which many might view as a good thing) so it is easier to customize, but it also means a lot of the standardization is lost. I know that within my own organization that is one of the huge selling points for our configuration management team. It doesn't matter what project they are getting a build from, they can run the same goals and get similar results. If Gradle gets to that same place then it might be just as acceptable, but then it will have lost the main feature you are saying is an advantage. Ralph
Gradle is a build tool, not a language. Joern was asking about it replacing Maven. I attended a presentation on Gradle at SpringOne and concluded it wouldn't meet the needs of my organization - it is somewhere between Ant and Maven. It isn't clear to me why one would want to switch from Maven to Gradle when the build is already working. Ralph On Feb 19, 2011, at 1:51 PM, 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.
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?
-- Ceki _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
On 20/02/2011 5:00 PM, Ralph Goers wrote:
Gradle is a build tool, not a language. Joern was asking about it replacing Maven. I attended a presentation on Gradle at SpringOne and concluded it wouldn't meet the needs of my organization - it is somewhere between Ant and Maven. It isn't clear to me why one would want to switch from Maven to Gradle when the build is already working.
AFAIK, Gradle is an in-language DSL. SBT is also an in-language DSL but in Scala. When you choose betweenr Gradle or SBT, you are also making a choice between Groovy and Scala to some extent. So, yes, it may seem that my answer to Joern was off topic but the language question bears some relevance to the topic at hand.
Ralph -- Ceki
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. I prefer Scala because of its type system and the fact that you can write a library in Scala that can be used by Java code. The fact that Groovy's syntax is closer to Java's is not appealing to me. The combination of Scala + SBT is very appealing. Ceki, I saw you started experimenting with Scala by porting a few JUnit tests. I took a crack at porting SizeBasedRolling test and submitted a pull request in github. Please let me know what you think. I'd be happy to help with future Scala/SBT experiments. On Sun, Feb 20, 2011 at 1:16 PM, Ceki Gülcü <ceki@qos.ch> wrote:
On 20/02/2011 5:00 PM, Ralph Goers wrote:
Gradle is a build tool, not a language. Joern was asking about it replacing Maven. I attended a presentation on Gradle at SpringOne and concluded it wouldn't meet the needs of my organization - it is somewhere between Ant and Maven. It isn't clear to me why one would want to switch from Maven to Gradle when the build is already working.
AFAIK, Gradle is an in-language DSL. SBT is also an in-language DSL but in Scala. When you choose betweenr Gradle or SBT, you are also making a choice between Groovy and Scala to some extent.
So, yes, it may seem that my answer to Joern was off topic but the language question bears some relevance to the topic at hand.
Ralph
-- Ceki _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
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. I prefer Scala because of its type system and the fact that you can write a library in Scala that can be used by Java code. The fact that Groovy's syntax is closer to Java's is not appealing to me. The combination of Scala + SBT is very appealing. Ceki, I saw you started experimenting with Scala by porting a few JUnit tests. I took a crack at porting SizeBasedRolling test and submitted a pull request in github. Please let me know what you think. I'd be happy to help with future Scala/SBT experiments. On Sun, Feb 20, 2011 at 1:16 PM, Ceki Gülcü <ceki@qos.ch> wrote:
On 20/02/2011 5:00 PM, Ralph Goers wrote:
Gradle is a build tool, not a language. Joern was asking about it replacing Maven. I attended a presentation on Gradle at SpringOne and concluded it wouldn't meet the needs of my organization - it is somewhere between Ant and Maven. It isn't clear to me why one would want to switch from Maven to Gradle when the build is already working.
AFAIK, Gradle is an in-language DSL. SBT is also an in-language DSL but in Scala. When you choose betweenr Gradle or SBT, you are also making a choice between Groovy and Scala to some extent.
So, yes, it may seem that my answer to Joern was off topic but the language question bears some relevance to the topic at hand.
Ralph
-- Ceki _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
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 Cheers, Joern.
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.
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?
Well, there are Gradle plugins to generate Eclipse and IDEA project files. IDEA 10 has basic support for Gradle, too, but I can't check it myself since my company hasn't bought the upgrade yet. The feature request for full-fledged support is here: http://teamsys.intellij.net/issue/IDEA-53476 As I said, I use both Maven and Gradle side-by-side at the moment so this isn't a big issue for me. The Maven build isn't able to produce the same result as the Gradle one since I add the Git HEAD hash to the properties of my application (which I simply wasn't able to do in Maven) but it is still able to create working results and I can still use the pom.xml for IDEA. The main reason I keep the poms around, though, is really Sonar. It's still lacking Gradle support so I have to keep it that way for a while longer... Cheers, Joern.
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?
We started off with Gradle on my current project, but we've moved back to Maven because of the lack of IDE support. The ease of sorting out the classpath in Eclipse and IDEA using Maven plugins makes up a lot for the pain associated with the rest of Maven. If the tool support catches up I would be inclined to use Gradle again; the lack of verbosity is a huge win in itself, and the cross between Maven's convention approach and Ant's flexibility without writing code in XML is great. (I've yet to look at SBT.)
IDE support for SBT is lacking too, so I also tend to use it side by side with Maven. On Mon, Feb 21, 2011 at 11:48 AM, Robert Elliot <rob@lidalia.org.uk> wrote:
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?
We started off with Gradle on my current project, but we've moved back to Maven because of the lack of IDE support. The ease of sorting out the classpath in Eclipse and IDEA using Maven plugins makes up a lot for the pain associated with the rest of Maven.
If the tool support catches up I would be inclined to use Gradle again; the lack of verbosity is a huge win in itself, and the cross between Maven's convention approach and Ant's flexibility without writing code in XML is great.
(I've yet to look at SBT.) _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
On 21/02/2011 5:48 PM, Robert Elliot wrote:
We started off with Gradle on my current project, but we've moved back to Maven because of the lack of IDE support. The ease of sorting out the classpath in Eclipse and IDEA using Maven plugins makes up a lot for the pain associated with the rest of Maven.
If the tool support catches up I would be inclined to use Gradle again, the lack of verbosity is a huge win in itself, and the cross between Maven's convention approach and Ant's flexibility without writing code in XML is great.
There is the Idea plugin for Gradle [1]. It looks like it could do the trick. -- Ceki [1] http://gradle.org/latest/docs/userguide/idea_plugin.html
participants (5)
-
Ceki Gülcü -
Craig P. Motlin -
Joern Huxhorn -
Ralph Goers -
Robert Elliot