...

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

• flex
• air

Redesigning the Mavenizer

Currently there are in general 2 Mavenizer parts:

• Air Mavenizer
• Flex Mavenizer

However it would be better to have 3 parts:

• Air Mavenizer
• Flash Mavenizer
• Flex Mavenizer

And have the Air and the Flash Mavenizer work on both Air and Flex directories.

This would make separations of each of these parts a lot easier and would make it easier to embed parts of the Mavenizer in other tools, such as Flexmojos or the upcomming Flex-Maven-Plugin for handling automatic download of Flash and Air resources.

Also it would be good to clean up the pom artifact generation as when going through the code, I could see different ways I used to create the poms, so overworking this would certainly clean up code.

General Mavenization of Artifacts

...

No matter if it's a standalone AIR SDK or an AIR SDK bundled inside a Flex SDK, all framework files are located inside the "frameworks/libs/air" directory. For each of the "swc" files in this directory a terminal Maven artifact is generated. If for a given "swc" file a matching "swf" and/or "swz" file exists, These are also copied to the target directory while keeping their initial file ending. (It seems that currently this copying of swf and swz files is not happening as I could only find code for this in the FlexFrameworkGenerator and not the AirFrameworkGenerator)

<dependency>
	<groupId>com.adobe.air</groupId>
	<artifactId>framework</artifactId>
	<version>{version}</version>
	<type>pom</type>
</dependency>

Mavenig the AIR "runtime" artifacs

In order to sensibly generate runtime artifacts, I think we first have to find out how these artifacts would need to be used at all. Simply zipping them up doesn't seem to be a good idea.

<dependency>
	<groupId>com.adobe.air</groupId>
	<artifactId>runtime</artifactId>
	<version>{version}</version>
	<type>exe</type>
</dependency>

Mavenizing Flash

In contrast to the Air runtime, the Flash part is a lot simpler, it generally consists of two files only. One runtime libary and the player/debugplayer itself. 

The ActionScript library is located in directories called "frameworks/libs/player/{version}", where the library itself is allways called "playerglobal.swc". 

<dependency>
	<groupId>com.adobe.flash</groupId>
	<artifactId>framework</artifactId>
	<version>{version}</version>
	<type>pom</type>
</dependency>

The Flashplayer / Flashdebugger is located in directoried called "runtmes/player/{version}/{os-code}". Depending on the os there are different target files.

Depending on the Flex version it seems some times the players were shipped and sometimes the debugger versions:

In contrast to the Mac zip files, the linux archives are a little tricky, as Java can't natively process them. For this we need to re-package them.

For this they are first unzipped and the resulting file is untared. The unpacked flash runtimes should now be a statically linked version consisting of only one file (flashplayer or flashplayerdebugger). When mavenizing these files are copied to the maven local repository instead of the archives.

Mavenizing the other artifacts simply consists of copying these files to the groupId "com.adobe.flash.runtime":

<dependency>
	<groupId>com.adobe.flash</groupId>
	<artifactId>runtime</artifactId>
	<version>{version}</version>
	<type>exe</type>
</dependency>

Eventually it would be good to have a classifier of "debugger" appied to the debug runtimes artifacts.

Mavenizing Flex