A full installation of the Flex SDK contains not only the Flex SDK, but also an embedded AIR SDK as well as the Flashplayer SDK (Which is actuallly just a version of the Flashplayer together with it's matching version of the playerglobal ActionScript library)

In order to mavenitze a Flex SDK therefore actually 3 mavenizations have to be performed: 

1. Mavenizaingtion of the AIR SDK
2. Mavenization of the Flash artifacts
3. Mavenization of the Flex SDK

The Air SDK however can be Mavenized as part of the Flex SDK or as a standalone SDK. It makes thingsa little easier that an AIR SDK buindled in a Flex SDk ist simply copied into that Flex SDK so it has the same directory structure.

Especially when it comes to the ActionScript libraries bundled in the Flex SDK, these are all mixed up in the frameworks/libs directory, so we have to define which libs have to be deployed to which SDK. 

Each SDK generally consists of 3 parts (Except the Flashplayer, which  doesn't have a compiler):

• Compiler
• Runtime
• ActionScript libraries (Framework)

The Mavenizer tool is able to mavenize an entire set of SDKs. As the Flex SDK depends on the AIR SDK and the Flashplayer, it processes all AIR SDKs first, after which the Flashplayer artifacts are generated. After this is done the acutal Flex SDK can be generated.

When referencing libraries, the Mavenizer generally generates a Hash of each library and then checks if an artifact with that Hash value is availalbe. If it is, that particular library is not used, and the existing one is referenced. From one FDK to another the referenced libraries don't change too much, so redeploying them every time a new FDK is published is not desirable. If a library has been used in a prior SDK, the artifact isn't re-deployed either and instead the version of the previous deployment is used. 

In order to allow mavenization of pure AIR SDKs as well as Flex SDKs, the Mavenizer expects the following directories

• flex
• air

General Mavenization of Artifacts

When mavenizing an Artifact in general only the source file is copied to it's Maven location and is given a valid Maven name. After copying the file a pom.xml is generated that references no other libraries. Depending on the type of file, a different packaging is used to generate the pom.xml file. In general this matches the file-ending ("jar", "swc").

In addition to these terminal Maven dependencies (because they don't reference any other artifacts), the Mavenizer can output pom.xml files that have dependencies. This is usually done to create "pom" type artifacts that bundle a set of dependencies together. When doing real Maven, this approach is not quite desirable, but we simply don't have any information on which library depends on which other. Therefore this approach is the simplest option.

Mavenizing AIR

When mavenizing, the Mavenizer goes through all AIR SDKs located in the "air" directory and then in a second pass, searches the "flex" directory for bundled AIR version it might not have found yet. After this the list of AIR versions is sorted to facilitize the recycling of libraries of previous versions. All SDKs are processed from the smallest version to the highest version.

Mavenizing the AIR "compiler" artifacts

All AIR SDKs seem to only exist of one library "adt.jar". It is only the 2.6 version that seems to use two additional libraries "baksmali.jar" and "smali.jar". It seems however that starting from AIR 4.0 the number of libaries has greatly increased.

Mavenig the AIR "runtime" artifacs

Mavenizing the AIR "framework" artifacts

Mavenizing Flash

Mavenizing Flex