mhalver (29) [Avatar] Offline
I really wish that the book would have included instructions for using Spock with Ant.

Considering that one of the sections in appendix A is called "Master example for Maven, Ant, and Gradle", someone looking at the toc would expect the book to include instructions on using Spock with Ant. Instead all that is there is a footnote expressing the author's personal bias against Ant which is somewhat humorous and somewhat offensive - Ant developers buying this book and considering building Spock support in are more likely to burn the book then follow through after reading that smilie Titling the section this and then leaving that coverage out is misleading.

Some people are forced to use Ant. Others actually like Ant: I don't like that Maven and Gradle tell me what to instead of doing what I tell them. Yes, I can configure them to work the way I want, but it is a lot of work, and once I have done that, the advantage of using them has mostly gone away. In Gradle's case, the options that need to be changed to set up a completely custom directory structure are VERY poorly documented. Ant does exactly what you tell it and no more and is very easy to build plugins for (Maven is almost as simple to do, but doesn't support scripting out of the box like Ant; Gradle does, but is much trickier to build a non-scripted plugin for). I have built plugins for all three for personal use, and Ant is the only one that I don't find myself consulting API documentation while I am working.

I would love to see a future edition add in the use of Ant in this appendix (even if the author still wants to discourage using it) as it would serve many readers. It isn't exactly trivial either: 1 - get Groovy (possibly through Ivy), 2 - Define the groovyc task for Ant using the provided plugin, 3- Compile testing code with the groovyc ant plug in, 4 - Run with the Ant JUnit task (It isn't exactly obvious that this would be the way to run the tests). The needing to compile the code is similar to Maven, but the non-obvious use of the JUnit task complicates things.

Otherwise, the book does a good job of covering this testing framework, but I do miss that coverage.
Kostis Kapelonis (53) [Avatar] Offline

I am sorry for my Ant comment. I certainly did not want to sound offensive. I do consider however Ant a legacy technology.

The problem with writing a book is the support that follows it. If I had presented Ant/Spock as a viable solution, I would also be forced to answer questions about this combination. Regarding the merits of Ant over Maven/Gradle, I have to disagree with you, but this is another discussion.

I am happy if you finally managed to run Ant and Spock together. Ideally you should add your findings in the official Spock documentation (you can open a pull request for this)

Many thanks for reading the book.

mhalver (29) [Avatar] Offline
The main issue I have is the title of that section. If you choose not to cover Ant, that is perfectly valid (although I doubt it is going away any time soon - it is still actively developed and used by many projects), however, to somebody looking at just the TOC for the book (which is all you can see on many online stores when looking at the book), they would expect Ant to be covered in that section based on that title. The mention of Ant should be removed from that title shortening it to "Master example for Maven and Gradle" to not be misleading.

As I said, I wish that coverage was included, but other than that the book is excellent. It is shorter than many other titles I have on similar technologies, but I can't see anything left out either. That probably speaks to both the design of Spock (that it is ultimately very compact) and to your writing (that you don't waste space with unnecessary detail or overly complex examples that hide the point under discussion).
Kostis Kapelonis (53) [Avatar] Offline
Ah! Ok, I see what you mean now.

Yes you are correct. The title is still talking about Ant. This should be removed.

Sorry for that. It wasn't done on purpose.

Many thanks for your feedback. Indeed, I spent a lot of time thinking about the examples of the book and how to keep them relevant. For each chapter I spent about 3 weeks on thinking about the examples, and 1 week to code/test them.