Flex 3 SDK + Eclipse : an encouraging union

Posted on February 18, 2008
Filed Under Computing & Software Systems | 13 Comments

On one of those rare occasions that I could be arsed to go out of my way to use precious “day-off” hours to tinker with software, I decided to find out how hard it would be to build flex apps without Adobe Flex Builder. With excellent (if outdated) starting points such as Darren Schall’s post and another update from Todd Sharp at cfsilence , I couldn’t really go wrong.

Barring a few hiccups, I was able to stand back and marvel at how awesome it is when bits of software from different walks of life just come together and play nice…

Getting a flex/eclipse dev environment going

After a fresh Eclipse install, I also needed the MDT-OCL, MDT-UML, EMF-SDO, GEF, XSD and VE-runtime (“JEM”) plugins. (I’m not sure why the graphical stuff is needed – haven’t yet figured out how you’d emulate flexbuilder’s design view… but maybe that’s not what those components are for). The best way to clue up on those eclipse features is to google “eclipse <plugin-name>”. Yeah I know… what would we do without google.

Eclipse

Eclipse, which I love (without necessarily being in love with it), has these ‘update managers’ that are *supposed* to let you install plugins just by pointing at update urls and having eclipse take care of the rest. Hmm.. not quite so. One of the eclipse projects (I forget which) had an update url which was broken purely because of a link to an xsl stylesheet that wasn’t even there.

Also, plugin dependencies at installation time (reminiscent of pre-friendly linux distro behaviour when installing software) made getting all those extra features installed a bit of a pain. In the end I just shoehorned them in by downloading the necessary .zips and extracting ‘em all over my eclipse install. Hey – it worked. But Eclipse loses points (from the point of view of this silly afternoon venture) because this was the step that took the most time.

However: Eclipse redeems itself almost completely with the ease with which you can associate the .mxml and .as file types, right down to specifying xml templates (kinda like fragments of xml) that are used during flex development. Which brings me to my next point: the flex xml schema itself.

Flex 3 Beta SDK

Adobe does not ship the XML schema definition file with the “free” SDK. Read that line again. Yeah. I really was *incredibly* pissed off about that. This is basically a complete refusal to allow another application to understand anything in the flex realm. After I calmed down though, I started to think that maybe this omission was perhaps a corporate strategy. There’s very little left that the full-featured Flex Builder application has going for it if Adobe just hands over the .xsd file. Anyhow. 10-billion demerit points for the SDK! For I dunno… poor interoperability.

In the end, I had to make do with the only version of the mxml schema still hanging around on the net: It’s a flex 1.5 .xsd modded over to ver 2, but well. It’ll do for now.

(Again, Eclipse gains points for easy integration of the xsd, after which – hey presto! – you have code completion).

The SDK also loses a few points for a rather frightening message when you run the compiler: a notice that it will expire in 30 days. I was like, “what?! I thought this was free / open source!” More effing and blinding then, until I come across something online that explains the notice: apparently it just allows them (Adobe) to halt support of older versions and betas, etc., but the sdk will always be free.

The other bit of weirdness with the SDK is that the compiler (mxmlc) couldn’t find my java runtime, which everything on my system up until now has been able to find. I don’t know why having the JDK in my PATH variable didn’t suffice. In the end I also added JAVA_HOME to my environment vars (I must have deleted it a while back) and it was happy.

FlashDevelop

FlashDevelop is an awesome little source editor for AS2 / AS3 that requires the .NET runtime. This is what I told eclipse to use as my actionscript editor. Flashdevelop and .NET are outside the scope of this post though – they both did their job and didn’t need tweaking, nor is either required for getting up on flex development with eclipse.

Ant

OK. So at this point, I can edit flex files, but now I need a way to build the final application. Enter Ant, the spidery make tool from Apache heaven. It has its quirks, but it really does do exactly what it says on the tin and in no time I was able to compile mxml and as files, apply a html wrapper, populate all the variables in the wrapper on the fly and see the results in a browser.

Verdict

I’m still impressed with Adobe for even handing out the SDK, and it’s great to have something like this to build both UI and backend systems – certainly it’s a huge improvement on Flash.

In terms of which tools were designed for playing nice with other systems, and for behaving in an expected manner, the ranking is as follows:

1. Eclipse (the most complex piece of the puzzle, but it did all the heavy lifting)
2. Apache Ant (the least troublesome)
3. Flex 3 beta SDK (a bit standoffish, but plays along)

All in all though, the end result is definitely a viable system for roll-yer-own flex development – not to be scoffed at!

*********************************

UPDATE JAN 2010 :

Things have moved on, but it appears a few people still hit this page – I would recommend building your solution around FLASHDEVELOP instead…

Tenuously Linked (blame my tagging):

• I’d vote for FlashDevelop, myself…
• Ant, Flex, Eclipse.
• handleTheImpossible(*state snafuState){ /*hmm…*/ }
• My caramel escape plan
• Malicious engineering

Comments

Copyright © 2007-2010 TINUUM. All rights reserved.