Deploying Flex FDKs was allways a job involving a lot of work. Normally Velo was responsible for deploying new FDKs using some tools and configurations that he didn't make open-source. Unfortunately in 2011 Adobe released allmost all FDKs in patched versions in order to eliminate some major security issues. Only a hand-full of these FDKs were ever deployed again and the repo was completely missing working versions of 4.6 and Apaches 4.8 FDKs.
In order to get around the problem of having to wait for Velo to re-deploy all of the FDKs, I created a Tool that allows to automatically manvenize any given Flex / Air SDK. This tool is even able to generate Apache FDKs. While I was at it, I took the chance to refactor the structure of the FDKs so flash, air, flex are now handed separately as well as fixing some general issues I was having with the old structure:
The Flash Player and the Playerglobal are now separately deployed under the groupId "com.adobe.flash.framework".
The Air Runtime and Airglobal are now separately deployed under the groupId "com.adobe.air".
The libraries which are also available as RSLs and SWZs are deployed using their real Versions (Now the SWZ Files can be downloaded from the official Adobe servers).
Additional poms are generated, that contain only a dependencyManagement section and allow automatically configuring the versions of the framework artifacts.
All Themes are provided as SWC themes (Usually there were some SWC themes and some provided as non-compiled resources).
Adobe FDKs are deployed under the groupId "org.apache.flex".
These changes made it necessary to refactor Flexmojos code as well as the poms of the testsuite. Flexmojos 5 will not be 100% compatable with the new FDKs and the testsuite will fail. So in general Flexmojos 5 and below work with the FDKs deployed by velo and which are publically available via Maven and Flexmojos 6 is the only tool compatable with FDKs created by the Mavenizer.
Using the dependencyManagement poms
The major difference to the classic FDKs is that Libraries are now addressed using ther natural version. For example the textLayout and osmf packages were ususally deployed using the same version as the FDK they were distributed as. This caused major problems when configuring the application to load the corresponding SWZ files from adobe servers. Deploying them in their real versions makes this possible again. Unfortunately this makes configuring the dependencies a lot harder as you have to know which explicit version of a library is contained in each FDK version. To make this easier a few new pom artifacs were added. These contain a dependencyManagement section which define the versions of artifacts based upon the versions in the FDK. With FM6 the way to define your dependencies is to omit the version of a flex artifact and import the version information from that dependencyManagement pom:
While making the Flexmojos test-suite pass for the Apache FDK I ran into serious trouble. Initially I wanted to make Flexmojjos use Adobe FDKs with the group-id com.adobe.flex and the Apache FDKs with org.apache.flex. But it turned out that having one Flexmojos work with both group-ids was not possible. One solution would have been to habe two builds of Flexmojos. One for Adobe and one for Apache FDKs.
In order to use Flexmojos with Apache FDKs you have to tell the Mavenizer to output the Apache FDKs using the Adobe group Id. I will not try to make Flexmojos work with Apache group ids as this will be handled by a completely new plugin I am currently working on.