This post is a bit of a follow up to my rant about Unit testing in Scala two days back. First let me tell you that that story actually has a happy ending. Eric Torreborne (creator of the Specs framework) immediately stepped up and helped me, and the problem seemed to be a lack of support for JUnit4 test running, which he subsequently implemented. I'm going to reintegrate
specs into my test suite later today. So that makes me happy. I might still retain JtestR. Actually, it would be a bit interesting to see the differences in writing tests in Ruby and Scala.
I spent some time on #scala on FreeNode yesterday. Overall it was an interesting experience. We ended up talking a bit about the unit testing bit, and Ant integration in particular. I'll get back to that conversation later. But this sparked in me the question why I felt that it was really important to have Ant integration. Does it actually matter?
I have kind of assumed that for a tool running on the JVM, that people might need during their build process, integration with Ant and Maven is more or less a must. It doesn't really matter what I think of these tools. If I want anyone to actually use the tool in question, this needs to work. In many cases that means it's not enough to just have a Java class that can be called with the Java-task in Ant. The integration part is a quite small step, but important enough. Or at least I think it is.
I am thinking that no matter what you think of Ant, it's one of those established tools that are here to stay for a long time. I know that I reach for Ant by default when I need something built. I know there are technologically better choices out there. Being a Ruby person, I know that Rake is totally superior, and that there is Raven and Buildr who both provide lots of support for building my project with Ruby. So why do I still reach for Ant whenever I start a new project?
I guess one of the reasons is that I'm almost always building open source projects. I want people to use my stuff, to do things with it. That means the barrier to entry need to be as low as possible. For Java, the de facto standard build system is still Ant, so the chance of people having it installed is good. Ant is easy enough to work with. Sure, it can be painful for larger things, but for smaller projects there really is no problem with Ant.
What do you think? Does it matter if you use established tools, that might be technologically inferior? Or should you always go for the best solution?
Sometimes I'm considering using other tools for build my own personal projects, but I never know enough to say with certainty I will never release it. That means I have two choices - either I use something else first and then convert it if I release it, or I just go with Ant directly.
Now, heading back to that conversation. It started with a comment about "an ant task for failing unit tests is severely overrated". Then it went rapidly downhill to "Haskell shits all over Ant for a build script for example", at which point I totally tuned out. Haskell might be extremely well suited for build scripts, but it's not an established tool that anyone can use from their tool chain. And further, I got two examples of how these build scripts would look, later in the conversation, and both of them were barely better than shell scripts for building and testing. Now there is a very good reason people aren't using shell scripts for their standard building and testing tool chain.
Or am I being totally unreasonable about this? (Note, I haven't in any way defended the technological superiority of Ant in this post, just to make it clear.)
Prenumerera på:
Kommentarer till inlägget (Atom)
4 kommentarer:
I see your point, but I think that as far as open source goes, any developer with plans to build-it-yourself would be able to do it with another utility, especially if you provided a quick note on how-to (but at a minimum explain that you used Tool X).
If you felt it would be too difficult to download it, you could provide it in the repository assuming the license is right.
Because of that, I don't think it's as important as you do. But, that may be also because of a bit of selfishness.
Thanks for the follow-up, Ola! (I just read your latest post) [I may just add a correction about my name, it is Torreborre.]
On the tooling subject, I started by looking at Buildr when developing specs, but I was recently helped by a lift developer (David Bernard) to use Maven.
I think that using established tools may not be as important as using established conventions. My project was already ready for Maven in terms of structure, as were the repositories, the versions naming,... We've seen the story for Rails!
Ant has its qualities (it is a portable build system for instance), but it is really annoying that there are so many ways to create a build file for things that are so common: compile, test, deploy.
Now, I am far from satisfied from Maven. I find it opaque, verbose and having to fire-up IntelliJ to write/modify a simple plugin makes me mad.
As Scala may be a better language for the JVM, Buildr/Ruby may be a better language for the Maven infrastructure. I will definitely have a look at it in the future.
Eric.
Indeed, established tools matter to get adoption. A programming language won't be successful without. Good posts around Scala testing, Ola, all of them were fun to read! Thanks. (A comment from a Java zealot who usually complains that Scala doesn’t have a whiz-bang eclipsy toolset already.)
Personally, I don't care what you do with/for ant, I won't be using it. How's that for pig-headed? And, more, I choose my tools so I don't have to think about ant. I guess I'm not a good example.
Skicka en kommentar