build systems @ devoxx

I couldn’t attend to the session on gradle because there was a Mockito session at the same time. For some unknown reasons I chose Mockito…

About gradle. Later on, Hans Dockter (AKA the gradle guy) was kind enough to help me writing a build.gradle for Mockito. Also, we played with multi-project builds and brand new gradle jetty plugin.

Then I went to Jason Van Zyl’s session, mostly on maven3. Third time lucky, right? Let’s not mention M1 or M2 here because I would have to use words gentlemen don’t use. Maven3 looks quite promising and I wonder what’s gonna be my first choice build system in mid-2009: gradle, maven3, or maybe something else? Felix made a wild experiment and cut an interesting, object-oriented java build system.

Oups, did I just call maven a build system? Oh, I know it is “not just a build tool” but 94.72% of developers use it to build projects so pardon me for taking this mental shortcut.

After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature. Then the natural fit for the build system is some scripting language. Quick reminder: xml is not a scripting language. Fully declarative build system like maven makes me eventually hit the boundary – it’s when the stuff that can be declared or configured is not good enough. Then I need a painless way of “specialising” my build, for example by scripting. Mind that I’m not nearly a build architect so don’t take my rambling too seriously.

I didn’t meant to complain about maven – there are many really good ideas in it. However, allow me to have my favorite build system different from maven. Good luck with your maven builds. You’ll never know when they stop building…

11 Responses to build systems @ devoxx

  1. We’ve also decided to give Gradle a try after talking with Hans. Usually I balk at a language trying to do two things: functional AND OO, declarative AND scripting… but in this case I think Groovy has a ton of value for being both a scripting language and capable of being declarative. Should anyone think that Groovy isn’t a declarative language I would point to the similarities between JavaFX and Groovy’s Swing building.

  2. Richard says:

    If you’re searching for new build systems/tools you might want to look at Quokka

    It was written by someone who saw maven’s faults and decided to write something better. It also supports dropping down into Ant or Scripting when needed. :-)

  3. Hi Szczepan,

    so what’s your favourite build solution ? And what are you using in your projects right now ?

    Tomek Kaczanowski

  4. szczepiq says:

    Hi Tomek,

    I don’t know yet :)

    I do a lot of python work lately, fortunately I can just script in python and I don’t have any dilemma about build systems.

    I commit to Mockito which is built by ant so far. I almost finished rewriting the ant to gradle but I will leave the ant script anyway. Mockito is open source so I need to use most popular / less surprising build system so that most java devs can build it and potentially contribute.

    At work my team helps other build masters maintaining serious maven architectures. We ran maven workshops, etc. Historically, 2-3 years ago I was an advocate of maven but well… every affection ends some day.

    I looked at different build systems and currently I’m quite excited by gradle. However, I haven’t used it that much yet. I bet I will develop some strong opinions in couple of weeks.

  5. Tomek says:

    Hi Szczepan,

    thx for your answer.

    When I started reading the last sentence of your reply (“I bet I will develop…”) I was sure that it will be something like “I bet I will develop a build tool of my own, superior to all existing ones”. ;)


  6. szczepiq says:

    You bet I always wanted to implement such thing but never had enough time / motivations :)

  7. […] not in XML. (This is one of the reasons why I like gradle and buildr). Also see this post about build and it’s inherent scripting […]

  8. Serena says:

    So this is a basic addaption of a model that I\’ve used for vnyriag ways of describing the relationship of Brand, Product and Service to each other, in particular with referenece to B-P-S being used as basic needs\’ within a customer lifecycle. I introduced community into the equation and ended wp with this diagram, which is a little flawed, but kinda makes sense. I\’m not sure where to go with it next though? So will take along to Laptopdance II tonight (the one in the middle where the hero gets frozen in carbonite) and see if we can work out wtf do to next, or at the very least decide wether its a load of old bollocks or not. (decklet here ppt 20kb) Bookmark to:

  9. sorry for the long delay, just have seen your comment. So, it’s hard to customize the processing at 12.1.x. However, the whole integration has been re-written for v.13.x in order to generify external system support. Please have a look into , it has expressive documentation. Also we don’t have a special scala gradle support at the moment. Not sure with the ETA, sorry@Oleg: there might be a bug with symlinks processing. Please try to define a path without symlinks as a gradle home. Android-specific import is performed by android plugin. That code was introduced at the IJ 13.x branch, i.e. it’s not available at 12.1.x.

  10. Haha. I woke up down today. You’ve cheered me up!

  11. Evi says:

    Using a mocking frrwamoek like mockito all fail when one attempts to refactor etc because of the use of magic strings to represent method names et al. If you have introduced interfaces then it should not be too much trouble to create anon inner classes within your tests and put the right asserts in the right spots.

%d bloggers like this: