Skip to main content

Maven (and Ant, and Make)

For some reason I've had a lot of ramblings in my brain lately, making me want to post. So here I go.

I've been reading up about Maven (thanks, Rob), trying to wrap my brain around it. And I'm torn. I can't decide if I think it's wonderful or if I hate it (most likely, it will resolve to being like most tools, which is "useful but with a handful of caveats").

For some background, most of my experience with automated build systems comes from Make. And let me tell you, other than the syntax (which is one of the worst crimes against humanity), Make is incredible. Make is less about procedurally defining your build, and more about creating a bunch of rules about what files you need, and how to go about generating them. It then recursively looks at the dependencies of those files, and how to generate them, etc. It's a thing of beauty. (Again, other than the syntax). When I was working on Anguna, my makefile did all sorts of crazy nasty things to build my project: converting room definitions, converting sprites and level graphics, using perl scripts to transform certain scripts into C code which then got compiled, etc etc etc. It was a weird, complicated build. And my makefiles were weird and complicated and ugly. But they were great in that Make automatically understood and handled knowing when to rebuild files (based on the sources changing) and when not to. And not just for C source, but for the whole build process.

Then I started doing java development at work. And for a long time, Ant was the defacto build system for java. This felt like a complete downgrade after working with Make. First, Ant is extremely procedural. Sure, there are targets that can depend on each other, but (as far I have found, not being an expert on Ant), the ability to check dependencies to avoid rebuilding only occurs for java source/class files. If I have to run weird commands to convert an image file to the right format, Ant doesn't seem to know how to check the source image file for changes before converting it. (Again, maybe I'm wrong, I rather hope so). And Ant's syntax is only marginally better than Make's. Instead of terse weird symbols and problems with tabs/spaces, everything is xml. Writing procedural code in xml is just dumb. So Ant felt like a step back from Make as far as overall flexibility and utility, but still wasn't terrible, as it still let you wire up weird builds and do whatever odd build steps you needed. I guess the biggest con of using Ant was that it didn't make the easy parts easy. Building and jar'ing a simple java project still required a good amount of xml.

Then along came Maven. I'm not hip and trendy enough to have started using Maven early on, but I haven't been able to avoid it forever. My first experiences with it were awesome, trying to build various existing open source projects -- you check out somebody's code, do "mvn install" and it actually goes and downloads dependencies and the build works the first time. When does that ever happen?

But when I started using Maven for some of my own projects, I started to get a little frustrated. The pom file (the maven equivalent of the makefile or build.xml) specifies almost nothing. What if I want to copy a bunch of files to a different place partway through my build? Or run some weird commands? What's actually going on?

As I'm learning, Maven has a lot of conventions. It's like Steve Jobs and Apple -- if you are happy doing it the way they want you to, it's great. If you try to do something different, beware. In Maven you spend less time specifying the steps you take in your build, instead you're mainly telling it what kind of build you are doing, and Maven assumes you are doing it the same way as everyone else, and then (hopefully) just works. In this case, Maven seems to be making the easy easy (unlike Ant). If you put your code in the right place and are doing a build that matches one of the many standard builds that exist (or that there are plugins for), then it's really easy, and everything just works.

Things get harder when you try to do something different, or weird. Unlike Ant and Make, you can't simply and easily tell it what steps you want to do -- the step definitions are all buried in layers of plugins and defaults. Not that it's not possible, but it requires digging in and mucking about with how maven really works. Unlike Ant (where accomplishing the easy things and the hard things are both a little bit of work), in the Maven the easy is REALLY easy and the hard is pretty hard.

The more I think about it, thinking through this by writing, the more I think Maven is a good thing, especially when you're willing to follow its conventions. But that doesn't always it's the right tool for every job.

Now I just need to read more about calling ant scripts from Maven (which is possible, and might solve some of my issues), and read up on Apache Ivy, which seems to be a useful tool for managing dependencies without living in a world as script as Maven's.


Popular posts from this blog

Retrospex 32 Review

RetrospexInternational recently sent me a couple units of their new handheld device, the Retrospex 32, a new dedicated GameboyAdvance emulator handheld.  To make the unit playable out of the box, they pre-loaded a handful of homebrew games, including Anguna, which is why they were kind enough to send me 2 of the units to play with.  I was pretty excited to get my hands on the device and try it (I loved my old GBA micro with a good flash cart!), and see Anguna running on it. So here's my thoughts after playing with it.

Their website lists the Retrospex 32 for £59.99, which is around $100 USD. It seems like it's marketed toward people into retro-gaming (which makes sense for a dedicated GBA emulator device). At that price, with that target market, and such a limited set of functionality (why not make it a multi-machine emulator, and emulate all the old consoles?), it would hopefully do a really good job of it.

The short version of my review: it doesn't. It has one job (emula…

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…