assertTrue is the professional blog of Luke Bayes and Ali Mills

I have Ant, why would I use Project Sprouts?

Posted by Luke Bayes Sun, 22 Nov 2009 19:35:00 GMT

I received a really good question today from a person I respect immensely that is considering Project Sprouts. I’m going to keep him anonymous as I haven’t asked his permission to reprint the question here.

This is something that I suspect lots of people consider when they see Sprouts for the first time. As I was formulating my response, It occurred to me that this should probably be shared more widely than a single email to a single person.

The Question

"In our projects we tend to use Ant and Maven, which seems to work fine so far. I’m not sure what Sprouts could give me. Of course I’m not completely happy with Ant, but will I be with Project Sprouts?"

Ant and Maven

The big win that you get from Ant is that it’s widely adopted and reasonably well understood – even where it’s not that well understood, Flash folks don’t seem too intimidated to muck around with XML all day.

If the following sounds like your project:

  • Your servers are built using Java, Ant and Maven
  • You have a team of developers that are already comfortable using Ant and Maven
  • Your system is already up and running
  • Your client builds are integrated with your server builds
  • You’re happy with how things are going

I think you should take a look at Sprouts, but it’s probably not worth digging up everything you already have working and trying to force this other technology into an already complicated stack…

Why not Ant and Maven?

If, on the other hand you find that:

  • Your build script has grown to hundreds of lines of tangled, node-based dependencies
  • It takes more than 10 minutes to bring a new development box online
  • You’re tired of firing up a Java IDE in order to support more complex features
  • You haven’t stopped fighting Maven since you both returned from the honymoon
  • You want to figure out this TDD thing
  • You’ve figured out the TDD thing, but you’re sick of writing all that boilerplate code
  • Your server build is completely separate from your client build
  • Your server is not written in Java

Sprouts could be exactly what you’ve been looking for.

Convention Over Configuration

Like Ruby when compared to Java, and Rails compared to anything else, Sprouts approaches the problem from a slightly different angle, and attempts to cover more ground with less developer effort.

The core of this idea, is that if you follow a set of simple, easy to understand conventions, life will be very, very easy and productive. If you want to fiddle with those conventions, life will get a little more complicated the further you stray.

This differs from most Java environments in that the convention is mostly missing and the developer must configure, and configure, and configure.

We’re trying to minimize the time spent in system and project configuration, so that we can get productive more quickly on the task at hand. We accomplish this by cutting down on the external steps required to get a system ready to code ActionScript (or MXML), and by providing a more flexible and robust set of tools to accommodate change over time.

Right, but what does that mean to me?

Once you have Java, Ruby and Ruby Gems installed, there are a handful of simple shell commands that will instantly generate a new project and automatically configure your system for compiling and debugging SWF files.

Java, Ruby and Ruby Gems are already installed on modern OS X machines, and very simple to get going on Windows and Linux.

Once you generate a project using Sprouts, one can immediately accomplish the following:

  • Generate new classes, test cases and test suites
  • Include a variety of publicly-accessible, FOSS libraries by simply editing the build script
  • Create a trusted SWF and launch it in the debug Flash Player while collecting trace output
  • Create a trusted Test SWF and launch it in the Debug Flash Player while collecting trace output
  • Create a trusted Test SWF and launch (and auto-close it) for Continuous Integration while collecting trace output
  • Create a SWC
  • Create AsDocs
  • Create a deployable SWF (optimize=true)
  • Render text-based ERB templates

All of these task helpers take advantage of a concept that’s similar to Maven in that your configuration is largely performed in a single ‘Project Model’, rather than duplicated throughout the build script.

I want to clarify here how much work is involved in creating and running a ‘trusted’, ‘debug’ SWF file and collecting trace output.

Flex Builder does a lot of this work for us and makes it seem like something simple – but as soon as you want to perform these builds outside of your IDE, you have a lot of work ahead of you.

  • Finding and installing the latest Flash Debug Player for your system
  • Finding and specifying the exact SDK version that you want to use for this project (not always found at FLEX_HOME)
  • Finding and editing the Flash Player Trust config file
  • Finding and tailing the flashlog.txt

Of course Adobe moves these files around depending on the version and variety of your Operating System, Flash Player and system default setting for SWF files. Sprouts gets around all that complexity for you. And it does it on Mac, Win and Linux.

This brings us to Rake

Rake is an amazing tool for writing build scripts. Rake exposes the full power of Ruby (a dynamic, interpreted programming language) to your build script with some simple conventions to manage transitive dependencies. Have you ever needed a feature that wasn’t quite available in Ant? You’re either forced to fire up a Java IDE and begin the code-compile-deploy process, or start composing much more complicated XML structures that seem to grow and grow.

With Rake, you simply write the requisite functionality in place and get back to work. If you want to later simplify your build script, you extract that code and require (or include) it from a separate text file.

Of course the Sprout Task Helpers, are composed of simpler entities. So, if your project has more complex build requirements than are available on our Project Model, it’s trivial to drop out of our provided helpers and take a finer-grained control over your build to whatever level of depth you find necessary.

And in Conclusion

If you’re happy with the build system you’re working with – please don’t change a thing!

But if you’re tired of fighting with whatever you use today, and even after the endless battles, winding up with a giant set of incomprehensible compromises, check out Sprouts – it might be exactly what you’ve been looking for….

Tags  | no comments

Comments

Your Reply

Comment Form.

Fields denoted with an "*" are required.