These days it is common to praise [[wikipedia:Gradle|Gradle]] and dishonest [[Maven]]. It is hard to find articles like [https://timboudreau.com/blog/maven/read Maven's Inflexibility Is Its Best Feature] that would try to put some balance into the ''build tool flamewar'' raging around.

These days it is common to praise [[wikipedia:Gradle|Gradle]] and dishonest [[Maven]]. It is hard to find articles like [https://web.archive.org/web/20211024174124/https://timboudreau.com/blog/maven/read Maven's Inflexibility Is Its Best Feature] that would try to put some balance into the ''build tool flamewar'' raging around.

It is true that [[Maven]] is far from perfect, and possibly [[Gradle]] learned from [[Maven]] mistakes in many areas, but there is one thing where [[Gradle]] regressed totally - and which [[I]] consider far bigger problem than any shortcomings of [[Maven]]: [[Gradle]] brought [[wikipedia:Halting_problem|halting problem]] into your build job!

It is true that [[Maven]] is far from perfect, and possibly [[Gradle]] learned from [[Maven]] mistakes in many areas, but there is one thing where [[Gradle]] regressed totally - and which [[I]] consider far bigger problem than any shortcomings of [[Maven]]: [[Gradle]] brought [[wikipedia:Halting_problem|halting problem]] into your build job!

== Post-Mortem ==

== Post-Mortem ==

[[Gradle|This essay]] attracted attention of [[Gradle]] community and [[I]] received some valuable feedback. [[I]] don't think it can change anything on the points raised in [[Gradle|this text]] as facts are facts, but it is useful to have wider context and understand motivation.

[[Gradle|This essay]] attracted attention of [[Gradle]] community (for example [http://delivervalue.blogspot.co.uk/2015/03/so-what-about-this-halting-problem-in.html Schalk Cronjé]'s post) and [[I]] received some valuable feedback. [[I]] don't think it can change anything on the points raised in [[Gradle|this text]] as facts are facts, but it is useful to have wider context and understand motivation.

The road to hell is paved by best intentions - and [[I]] am sure [[Gradle]] guys know it. If you listen to whole (or just jump to 48th minute) [http://www.infoq.com/presentations/build-system-concepts presentation by Hans Dockter], the father of [[Gradle]], you will notice. Let me quote: "We just don't know if someone calls {{JDK|java/lang|System}}.currentTimeMillis() here... This is I would say the biggest design flaw!"

The road to hell is paved by best intentions - and [[I]] am sure [[Gradle]] guys know it. If you listen to whole (or just jump to 48th minute) [http://www.infoq.com/presentations/build-system-concepts presentation by Hans Dockter], the father of [[Gradle]], you will notice. Let me quote: "We just don't know if someone calls {{JDK|java/lang|System}}.currentTimeMillis() here... This is I would say the biggest design flaw!"

See? [[I]] am not making anything up. The fact that [[Groovy]] is [[wikipedia:Turing_complete|Turing complete]] is the biggest design flaw according to father of [[Gradle]].

See? [[I]] am not making anything up. The fact that [[Groovy]] is [[wikipedia:Turing_complete|Turing complete]] is the biggest design flaw according to father of [[Gradle]].

Maybe you are a [[Gradle]] fan and nothing mentioned so far convinced you. At the end, what is wrong on having build system subject of [[Wikipedia:halting_problem|unidentified complexity]]. You run it and when it computes the classpath, you write it down into static file which can then be consumed by various IDEs. Yes, this is possible, but it is upside down! Moreover unsecure.

Maybe you are a [[Gradle]] fan and nothing mentioned so far convinced you. At the end, what is wrong on having build system subject of [[Wikipedia:halting_problem|unidentified complexity]]. You run it and when it computes the classpath, you write it down into static file which can then be consumed by various IDEs. Yes, this is possible, but it is upside down! Moreover unsecure.

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant or [[Groovy]] (in spite [[I]] would rather advocate using [[AnnotationProcessor]]s as much as possible). But the core aspects of the project should be understandable without running any code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant]] or [[Groovy]] (in spite [[I]] would rather advocate using [[AnnotationProcessor]]s as much as possible). But the core aspects of the project should be understandable without running any code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Another issue is CPU time: there are tons of services around the globe ([[wikipedia:Ohloh|Ohloh]] comes to my mind) that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

Another issue is CPU time: there are tons of services around the globe ([[wikipedia:Ohloh|Ohloh]] comes to my mind) that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

[[Gradle|This essay]] attracted attention of [[Gradle]] community and [[I]] received some valuable feedback. [[I]] don't think it can change anything on the points raised in [[Gradle|this text]] as facts are facts, but it is useful to have wider context and understand motivation.

[[Gradle|This essay]] attracted attention of [[Gradle]] community and [[I]] received some valuable feedback. [[I]] don't think it can change anything on the points raised in [[Gradle|this text]] as facts are facts, but it is useful to have wider context and understand motivation.

The road to hell is paved by best intentions - and [[I]] am sure [[Gradle]] guys know it. If you listen to whole (or just jump to 48th minute) presentation by Hans Dockter, the father of [[Gradle]], you will notice. Let me quote: "We just don't know if someone calls {{JDK|java/lang|System}}.currentTimeMillis() here... This is I would say the biggest design flaw!"

The road to hell is paved by best intentions - and [[I]] am sure [[Gradle]] guys know it. If you listen to whole (or just jump to 48th minute) [http://www.infoq.com/presentations/build-system-concepts presentation by Hans Dockter], the father of [[Gradle]], you will notice. Let me quote: "We just don't know if someone calls {{JDK|java/lang|System}}.currentTimeMillis() here... This is I would say the biggest design flaw!"

See? [[I]] am not making anything up. The fact that [[Groovy]] is [[wikipedia:Turing_complete|Turing complete]] is the biggest design flaw according to father of [[Gradle]].

See? [[I]] am not making anything up. The fact that [[Groovy]] is [[wikipedia:Turing_complete|Turing complete]] is the biggest design flaw according to father of [[Gradle]].

[[Gradle]] might have fixed few [[Maven]] bugs, but the flaw introduced in [[Gradle]]'s core ranks [[Gradle]] along [[Ant]]. Into [[Ant]]-age!

[[Gradle]] might have fixed few [[Maven]] bugs, but the flaw introduced in [[Gradle]]'s core ranks [[Gradle]] along [[Ant]]. Into [[Ant]]-age!

== Summary ==

== Summary ==

My friends keep talking about the greatness of [[Gradle]] and when I bring the problem of [[Wikipedia:Turing_Completeness|Turing completeness]] - e.g. [[Wikipedia:Halting_Problem|halting problem]] - they just nod their heads, admit it is a problem, but continue to use [[Gradle]]. Fine with me. By writing this essay I don't expect people to stop using [[Gradle]] - [[I]] just want them to stop claiming [[Gradle]] is superior to [[Maven]].

My friends keep talking about the greatness of [[Gradle]] and when [[I]] bring the problem of [[Wikipedia:Turing_Completeness|Turing completeness]] - e.g. [[Wikipedia:Halting_Problem|halting problem]] - they just nod their heads, admit tooling is a problem, but continue to use [[Gradle]]. Fine with me. By writing this essay [[I]] don't expect people to stop using [[Gradle]] - [[I]] just want them to stop claiming [[Gradle]] is superior to [[Maven]].

[[Gradle]] might have fixed few [[Maven]] bugs, but the flaw introduced in [[Gradle]]'s core ranks [[Gradle]] along [[Ant]]. Into [[Ant]]-age!

[[Gradle]] might have fixed few [[Maven]] bugs, but the flaw introduced in [[Gradle]]'s core ranks [[Gradle]] along [[Ant]]. Into [[Ant]]-age!

== Cloud and Security Issues ==

== Cloud and Security Issues ==

Maybe you are a [[Gradle]] fan and nothing mentioned so far convinced you. At the end, what is wrong on having build system subject of unidentified complexity. You can run it and when it computes the classpath, you can write it down into static file which can then be consumed by various IDEs. Yes, this is possible, but it is upside down! Moreover unsecure.

Maybe you are a [[Gradle]] fan and nothing mentioned so far convinced you. At the end, what is wrong on having build system subject of [[Wikipedia:halting_problem|unidentified complexity]]. You run it and when it computes the classpath, you write it down into static file which can then be consumed by various IDEs. Yes, this is possible, but it is upside down! Moreover unsecure.

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant]] (or [[Groovy]]). But the core aspects of the project should be understandable without running code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant or [[Groovy]] (in spite [[I]] would rather advocate using [[AnnotationProcessor]]s as much as possible). But the core aspects of the project should be understandable without running any code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Another issue is CPU time: there are tons of services around the globe ([[wikipedia:Ohloh|Ohloh]] comes to my mind) that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

Another issue is CPU time: there are tons of services around the globe ([[wikipedia:Ohloh|Ohloh]] comes to my mind) that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant]] (or [[Groovy]]). But the core aspects of the project should be understandable without running code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Generic information like classpath, etc. should be extractable without running unknown code. So the core of the build configuration should in fact be those files consumed by IDEs. If there is anything else needed for the actual build, it could be written in [[Ant]] (or [[Groovy]]). But the core aspects of the project should be understandable without running code. Because you don't want your IDE to hack your computer after you checkout a [[GitHub]] project and browse to its sources or open one of its files in editor!

Another issue is CPU time: there is tons of services around the globe that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

Another issue is CPU time: there are tons of services around the globe ([[wikipedia:Ohloh|Ohloh]] comes to my mind) that provide you indexing services over source code. Usually they just analyze commits, do static analysis of the code, etc. But there is nothing stopping them to understand structure of [[Maven]] projects and know cross-dependencies and resolve symbols to proper fully qualified names. However nobody is going to offer such service for generic [[Gradle]] projects! Because in order to analyze them you need to run foreign computation and that can eat enormous amount of CPU and do potentially anything and nobody is willing to offer free computation time so easily to everyone!

[[Gradle]] is designed to be insecure and hackers (real ones, not coders) have to love that!

[[Gradle]] is designed to be insecure and hackers (real ones, not coders) have to love that!

We have all heard about [[wikipedia:Design_pattern|design patterns]] and how useful they are. [[Maven]] in fact excels in defining such patterns: Do you want to compile using [[JavaC]]? Well, there is the ''maven-compiler-plugin'' - the plugin is in fact pattern - it is a solution to recurring problem. But rather than trying to recognize the ''pattern'' from a ([[Java]] or [[Groovy]]) source code, you directly speak the pattern's [[language]] - you name it in the pom file and declaratively adjust it to suite your particular use-case. The fact that one has to use different [[language]] (well over hyped [[XML]]) to express a use of a ''pattern'' is in fact perfect - one can stays [[clueless]] - and is not tempted to hack.

We have all heard about [[wikipedia:Design_pattern|design patterns]] and how useful they are. [[Maven]] in fact excels in defining such patterns: Do you want to compile using [[JavaC]]? Well, there is the ''maven-compiler-plugin'' - the plugin is in fact pattern - it is a solution to recurring problem. But rather than trying to recognize the ''pattern'' from a ([[Java]] or [[Groovy]]) source code, you directly speak the pattern's [[language]] - you name it in the pom file and declaratively adjust it to suite your particular use-case. The fact that one has to use different [[language]] (well over hyped [[XML]]) to express a use of a ''pattern'' is in fact perfect - one can stays [[clueless]] - and is not tempted to hack.

Of course, something there is no existing pattern (e.g. [[Maven]] plugin) to use. What one has to do? Define new pattern! E.g. create new [[Maven]] plugin - e.g. solution to recurrent problem - code it in [[Java]], but hide the code and expose only its declarative configuration. How structured! How architectural! How much better than classical hacking!

Of course, some things cannot be achieved by using existing patterns (e.g. [[Maven]] plugins). What one has to do then? Define new pattern! E.g. create new [[Maven]] plugin - e.g. solution to recurrent problem - code it in [[Java]], but hide the code and expose only its declarative configuration. How structured! How architectural! How much better than classical hacking! Of course one can run into the [[wikipedia:halting_problem|halting problem]] issues in [[Java]], but it is far easier to verify correctness of implementation of few patterns than check correctness of every build script.

Because we all know what you do when ready made solution cannot be found in [[Ant]] and alas, also in [[Gradle]]: you hack. You use all the power of [[wikipedia:Turing_completeness|complete programming language]] around to write a solution. Thinking about patterns comes later - if ever! As a result majority of [[Gradle]] build scripts will have some non-standard customization.

Because we all know what you do when ready made solution cannot be found in [[Ant]] and alas, also in [[Gradle]]: you hack. You use all the power of [[wikipedia:Turing_completeness|complete programming language]] around to write a solution. Thinking about patterns comes later - if ever! As a result majority of [[Gradle]] build scripts will have some non-standard customization.

We have all heard about [[wikipedia:Design_pattern|design patterns]] and how useful they are. [[Maven]] in fact excels in defining such patterns: Do you want to compile using [[JavaC]]? Well, there is the ''maven-compiler-plugin'' - the plugin is in fact pattern - it is a solution to recurring problem. But rather than trying to recognize the ''pattern'' from a ([[Java]] or [[Groovy]]) source code, you directly speak the pattern's [[language]] - you name it in the pom file and declaratively adjust it to suite your particular use-case. The fact that has to use different language (well [[XML]]) to express a use of a ''pattern'' is in fact perfect - one can stay more [[clueless]].

We have all heard about [[wikipedia:Design_pattern|design patterns]] and how useful they are. [[Maven]] in fact excels in defining such patterns: Do you want to compile using [[JavaC]]? Well, there is the ''maven-compiler-plugin'' - the plugin is in fact pattern - it is a solution to recurring problem. But rather than trying to recognize the ''pattern'' from a ([[Java]] or [[Groovy]]) source code, you directly speak the pattern's [[language]] - you name it in the pom file and declaratively adjust it to suite your particular use-case. The fact that one has to use different [[language]] (well over hyped [[XML]]) to express a use of a ''pattern'' is in fact perfect - one can stays [[clueless]] - and is not tempted to hack.

Of course, something there is no existing pattern (e.g. [[Maven]] plugin) to use. What one has to do? Define new pattern! E.g. create new [[Maven]] plugin - e.g. solution to recurrent problem - code it in [[Java]], but hide the code and expose only its declarative configuration. How structured! How architectural! How much better than classical hacking!

Of course, something there is no existing pattern (e.g. [[Maven]] plugin) to use. What one has to do? Define new pattern! E.g. create new [[Maven]] plugin - e.g. solution to recurrent problem - code it in [[Java]], but hide the code and expose only its declarative configuration. How structured! How architectural! How much better than classical hacking!