I agree that having external dependencies on 3 SWCs is heavy; but don’t forget that your project will only compile in the classes that it needs from them. As it currently stands as3commons-reflect has dependencies on as3commons-lang and as3commons-logging; although it would be possible to remove these dependencies by a bit of hacking, I would rather not have to rely on a forked 3rd party library.

I am not really up for writing my own reflection library at the moment, the main reason being that I see no need to reinvent the wheel; however, I am also not bound to using as3commons-reflect to do the work. I had a quick scout around and found Spicelib-reflect which could well fit the bill; but if anyone out there knows of a lightweight, and self contained reflection library then please let me know.

If you’re using an CI server to build, yes, it makes sense to use MXMLC locally. Or you could have separate projects dedicated to unit testing your code and those could use FDT’s compiler to runs tests without compiling your whole project…..hey I’m trying to work in FDT’s compiler in here in some way

Thanks for the suggestion about using Sonatype’s Nexus.

Project References in FDT 4.3 look great for small teams, and they are clearly more powerful than using Linked Resources alone. However, my issue (and this goes for using FDT’s compiler over MXMLC) is that it couples your entire build process to FDT – there’s no great harm in this for day-to-day development (especially if you’re an FDT fan!) but what about when you want to get the project building within a Continuous Integration environment where FDT is not available? Personally I’m of the opinion that your build chain should be 100% independent of your IDE.

As for Maven; when you a missing a dependency (ie: a SWC), Maven will head off to the repo and pull it down to your local machine (into your MAVEN_HOME folder, usually ~/.m2); the next time you go to resolve the dependencies Maven will check your MAVEN_HOME folder and skip over any artifacts it already has.

And lastly, yes, I completely agree that it would be a bad idea to rely on a public Maven repository – you really do need to treat them as “mission critical” systems when they are so tightly coupled to your build process – this is why I would 100% recommend setting up your own Maven Repo using something like Sonatype’s Nexus – not only can you upload artifacts to your internal repo, but you can also get it to mirror public repo’s (syncing the artifacts between the two) – that way if the public repo goes down, your build will continue unaffected. Obviously your local repo needs to be backed up incase the machine goes bang – you could even put it under VCS should you wish

The thing that I really like about externalising your build dependencies from your source code (using either Maven, Ivy, Gradle, etc) is that it provides (and maintains) a very clear separation of responsibilities – code that your maintain and develop and libraries which your code makes use of.

Great article. It was very informative and easy to read. I have some comments / questions.

I totally agree that linked libraries are terrible. I stopped using them and encourage all other developers to do the same.

In your build file, how about creating a ‘build.properties’ file and setting the FLEX_SDK home in that. That might make it easier for people to share your build script.

Check out our project references implementation. I think a lot of the issues you raise about project dependencies can be solved quite elegantly with that – e.g. create an ‘includes’ property in your SVN repository that checks out a ‘lib’s project that has all your .SWCs in there linked, and have your projects and module projects link to that project.

This method has you using MXMLC – which is terribly slow. I suggest you use FDT’s compiler which is much, much faster than both MXMLC and FCSH.

I understand Maven is very popular; however, this makes me nervous. Every time your compiling, you’re re-downloading your libraries. Also, these libraires are not controlled by you. You’re using adobe’s repository…what if it goes off line or they stop hosting that particular version of a library you’re referring to (say in 3 years). Then anyone who checks out the project is SOL.

I think it’d be better to host all the dependencies within the same repository your project exists and just have it set up with your VCS to handle your dependencies.