Jan 24
We need a package manager like RubyGems for distributing Flex components – Revisited
About a year ago I wrote a post about how the Flex/As3 community needs a package manager like RubyGems for managing libraries and components.
Well, I have some good news. Recently I’ve learned about two potential solutions to this problem.
The first I learned about from a comment on the original post by Luke Bayes. Here is an excerpt:
I’ve been working on ’sprouts’ for the past year and finally landed on an architecture that actually sits on top of Rubygems for package management. Even though we have a functional pre-alpha in the wild right now, we expect to release a production-ready build before the end of January 2008 that will really support versioning via Rubygems the repository.
Check it out: http://www.projectsprouts.org
The second potential solution is a Flex plugin for Maven. It appears that it is still under development, but it looks promising. You can check it out here.
January 24th, 2008 at 7:21 am
Hello
if you are interested in a Flex2 maven2 plugin, you can check this project : http://sourceforge.net/projects/mvnflex2plugin/
It’s an open source project I use. Still in development but works really fine.
Regards
January 24th, 2008 at 8:24 am
Would it not be better to build it on top of Eclipse? and integrate with svn or something?
January 24th, 2008 at 9:13 am
Hey Derek, thanks for the post!
We’re jamming right now to get the next release out that is fully built on top of RubyGems, Rake and Rails Generators. We’re actually starting to see a community form over here!
I wanted to address the question that Campbell just asked if it’s alright.
I considered deep Eclipse integration when working on Sprouts, but I wanted tools that support development without being prescriptive about actual IDE choices. I am planning on building some generators that will emit Eclipse .project files so that you don’t have to duplicate project configuration in Flex Builder.
As far as SVN integration, if you build a project with Sprouts, anyone on your team can simply check it out of version control, run rake against it and instantly have the Flex SDK, the debug Flash Player, all referenced libraries (swc or source), and be compiling your application. One command. I’m not sure how much deeper that could get!
January 24th, 2008 at 5:46 pm
Luke: I don’t see the difference between tying yourself to Ruby vs. tying yourself to eclipse. In fact, Ruby seems the more esoteric choice, as more people will have eclipse installed than Ruby. Don’t get me wrong, I’m on Linux, so I have Ruby installed anyways, but if tie your product to Ruby, the only people that use it will be the people that use Ruby on a day-to-day basis.
Anyways, it seems to me that for a project of this breadth to succeed, you would have to have a very high user adoption. Having only dabbled in Ruby, I don’t know how difficult it is to add something to Gems, but I’m assuming that it takes some knowledge of Ruby.. So all of your contributors will have to know Ruby too. It seems to me that you’ll have to mask the whole Ruby aspect of the project in order to get a reasonable people to contribute/use this.
just my $.02
January 25th, 2008 at 7:31 pm
Hey Dusty,
You do make some really good points and I appreciate the discussion. I’ll attempt to answer some of your questions here….
The main difference between Ruby and Eclipse is that Eclipse is an Integrated Development Environment (IDE), while Ruby is a programming language. This is a crucial difference because choosing an IDE is a deeply personal decision that for me (and I’m sure many others) changes over time. During my career, I have edited code with a wide variety of tools, just to name a few, I have used Director, Flash Authoring, Visual Studio, NetBeans, HomeSite, Primal Script, TextPad, TextMate, Emacs, FDT (Eclipse), Aptana (Eclipse), Flex Builder (Eclipse) and RDT (Eclipse).
I need an automated build system that can follow me around from IDE to IDE, regardless of my operating system or development tool choices. Additionally, a build environment should never depend on a particular IDE, what about those of us that want to use Continuous Integration tools? We need a server somewhere (running any operating system) to compile and run our application and test harness, and in my experience, this server is usually running some form of *nix.
You make some good points about some users having to install Ruby in order to get up and running. I was told not too long ago that roughly 50% of the people using Flash were running OS X. This means that at least 1/2 of the target audience of Sprouts already has Ruby and Ruby Gems.
Additionally, even for the other half, isn’t it much more challenging for someone to:
* Find, download and unpack the Flex SDK
* Update their system path to include the sdk bin directory
* Find, download and install the Flash Debug Player
* Depending on the version, figure out where Flash Player reads the mm.cfg file. (This lets you tell the Flash Player to write trace output to a log file)
* Depending on the version, figure out where Flash Player writes the trace output log file (So that you and read it on each exection)
* Depending on the version, figure out where Flash Player writes reads the trust files (that allow you to load content both locally and from the network while debugging)
* Select one of the many tools that reads the Flash Player trace output log file, and get it installed, and configured
* Find download and install AsUnit or FlexUnit
* Figure out how to get a test harness written and running
* Decide how to structure an ActionScript project
* Find download and install any other libraries that you’d like to use and keep them up to date
* Figure out how to integrate your IDE with your choice of continuous integration tools
* Get each and every person on a team to repeat this process
* As the project grows to include more or different tools, each team member must manually update their build environment or IDE settings
Sprouts does all of these things for ActionScript 2, ActionScript 3 and MXML development, and the only thing you need to do is install Ruby and RubyGems. As your build script is updated and checked into version control, your team members simply update their local copy and the next time they do a local build, they will receive any new or different tools or libraries.
As far as creating new gems, you are absolutely correct that it can be challenging. This is why we have built (and are still refining) some very simple Rake tasks that make this process much more like filling out a form than writing code. It is still Ruby code, and your point is valid. This may be a problem for some people. I do hope most people will agree that the hurdle is much smaller on this side than the other.
Your final point is a very good one. I am intensely curious about how intimidating Ruby might be for people that are currently writing ActionScript. I am encouraged by how easily HTML and JavaScript developers seem to be able to get productive with Ruby On Rails. Additionally, from a Sprout end user’s perspective, the exposure to Ruby is actually minimal. You have to touch Ruby when you deal with your build scripts, but this should be less intimidating, more feature rich (and far less fragile) than dealing with shell scripting or Ant tasks. I agree that it would be ideal if Sprouts had ridiculously wide adoption, but I’m not convinced that it’s critical for it to be successful. This is primarily because our library and tool packaging formats don’t require anything on the part of the library or tool developers. We can package and distribute open source and proprietary libraries and tools from their existing distribution points, by simply editing a simple text sprout specification.
Ultimately, Sprouts does more than any other automated build tool that I know of and the only thing an end user needs is Ruby and RubyGems. I hope you give it a try sometime and let us know what you think!
Thanks,
Luke Bayes
http://www.projectsprouts.org
February 3rd, 2008 at 10:45 pm
[...] building test suites, even installing essentials like the Flex SDK for you. There has been some discussion on FlexOnRails and also at the AssertTrue blog itself (the AssertTrue people are the same ones who [...]