We’ve been getting back into gear to start development of CoSolvent Flash Player version 2; which will really be the 5th major release of our core logic as the player was previously a more or less nameless piece of internal code.  The new version will be based on Adobe’s OSMF which we’ve been following with interest for quite some time now.

We made a couple decisions up-front, and one of them was to import the latest release code drops from OSMF into an internal git repository; that way if we ever need to make any patches we have the code right there, and anyway as with any open source project it can be very useful to go through the source code to understand how best to use it.  So that decision brought on the next, which was: do we go ahead and setup to build the osmf.swc library ourselves.  After debating this, we decided that it would provide useful experience.  Alas the OSMF SVN lacks a decent build script, seeming to rely on FlashBuilder.  Luckily the Strobe Media Player does have a basic set of ANT build scripts.  Now, I’ve been using ANT for quite some time, and everytime I have to use it on a new project I ask myself: isn’t there anything better?  So far the answer has been “no”.  So, I started working through an attempt to modularize the SMP build script.  I believe I managed to get something that was workable, while being fairly ugly; however along the way I decided that the build for CFP 2.0 should be cleaner if at all possible and decided to go though another search.

Of course one of the obvious tools for any Java developer such as myself has got to be Maven, although up until now I have avoided it, having found it approach too constrictive for my comfort, and that making the transition seems to involve an awful lot of new things to learn, which are not super well documented (not that most other open source tools are really much better).  We also have a (so far) internal tool built using the Eclipse RCP framework, and had also started to look at the e4 projects as the next logical step there; but again, the Eclipse build tooling always has struck me as incredibly non-user friendly.  The big problem we run into is that, because a number of tools that we want access to are part of various plugins (such as XML editing), we end up shipping a whole bunch of the IDE functionality, and that creates a huge set of dependencies to manage.  Now, if you have all day, you can simply re-provision them each time you need to build, downloading the latest stable releases, but that is not going to work for incremental builds.  So we are left with the question of managing a “target platform” full of modules (features and related plugins) that we want to keep up-to-date, and we don’t have a separate build developer.  One of the developments that caught our attention was the Tycho project, which seemed to address some of the issues, and since Tycho is built on top of Maven3 that seemed to provide some added incentive to consider moving to Maven.

Starting out with maven was somewhat ugly, as the maven way of doing things seems to be mostly derived from the process that a Java project might need, but we kept learning.  There is a “flex mojo” to add the ability to call mxmlc and compc from within a maven build as a semi-standard part of their lifecycle; however we quickly ran into a problem.  We need to control the version(s) of flex we are compiling with/against.  Apparently this used to be possibly, however after getting a few too many complaints from users who’d shot themselves in the foot with a path issue, the one guy who maintains the flex mojo basically decided to do his best to make this “impossible” for new users (see his discussion board postings).  In addition to creating technical problems, the attitude also raised a number of questions in our minds about if we really wanted to go that route.  In the end we decided that since the Tycho tool chain was not yet ready for us (or we weren’t ready for it), there was not really a compelling reason to use Maven.  So it was back to the drawing board.

After looking at numerous tools, I finally rediscovered Gradle.  I say rediscover because I’d previously seen it, when it was in a much less mature state.  Anyway, a quick google showed that not only would it be possible, due to Gradle’s built in support for ANT tasks, to use the Adobe mxmlc and compc tasks, but that just recently work had started on a plugin for adding even better support for Flex development into Gradle as a plugin – GradleFx

So, I started working on a test of using gradle to compile the OSMF code and plugins.  At this point, as I’d anticipated, I managed to run into a number of beginner issues; however I have been able to work my way through them, with the kind help of input from the GradleFx developers.  One thing I’ll note here is that you can avoid having to “install” the GradleFx plugin into a local maven cache by simply putting it in a local folder and declaring that as a “flat repo” like:

1
2
3
4
5
6
7
8

buildscript {
     repositories {
        flatDir name: 'localToolsRepository', dirs: "${buildTools}/lib"
    }
    dependencies {
        classpath group: 'org.gradlefx', name: 'gradlefx', version: '0.2.1.ipov', ext: 'jar'
    }
}

Note that the buildscript closure is evaluated right away, before the rest of the build, so if you want to use any variables, such as ${buildTools} in the example above, then you have to define them in a gradle.properties file.

I found that cloning the GradleFx repo enabled me to look over the code and get a better feel for what its doing, as the documentation is still a little light; however I soon found that I had a couple of ideas for some changes to the GradleFx code.  Since this is on GitHub, I decided to try my first ever GitHub hosted fork.  The process seems to have gone well, and so far I’ve been able to contribute a small change in the path handling.  I am currently working on code to add explicit includeSources and includeClasses properties to at least the compc code, as currently the compc implementation is using all the declared source-paths as include-sources too, which is going to work most of the time, but not all.  This should then mean you can reuse .flexLibProperties – something that the SMP build does, but much more simply.  I have the following as a part of a multi-project build (OSMF comes as several different components that I’m building separately):

120
121
122
123
124
125

def flexLibProperties = new XmlParser().parse( project.file('.flexLibProperties') );
def incClasses = [];
flexLibProperties.includeClasses.classEntry.each {
    incClasses.add( it.'@path' );
}
project.tasks.compile.includeClasses = incClasses

I am considering pushing my OSMF repo to GitHub, but my big hang up is that right now I am unsure how much TLC I’m going to be able to give it, and I don’t want to create any false expectations from others.  For instance, if it becomes clear that we’re not going to need to have the ability to build OSMF ourselves, then it would be much simpler to just use the latest binary.  However, in the mean time I intend to try and post a few other tips and try to contribute any other ideas I have to the GradleFx project.