Moving From Adobe Flex 4.6 to Apache Flex 4.13 with FlexMojos

I was very excited for the handover of the Flex project from Adobe to an Apache project.  After a few years I was finally given permission to move our product from Adobe Flex 4.6 to Apache Flex 4.13.  Here are my notes on the process in the hopes that they help somebody else in the same situation.

For some background our product was compiling using FlexMojos 4.0-RC1 and Adobe Flex version 4.6.  I decided to go with the least moving parts approach, which meant I made the upgrade in two steps.  First I upgraded the FlexMojos version to version 6.0.1 and then I upgraded to FlexMojos 7.0.1 and Apache Flex 4.13.

Up first was the upgrade to FlexMojos 6.0.1.  This version of FlexMojos supports both Adobe and Apache SDK's, but due to difficulties in supporting two different group ids, it uses the com.adobe groupID for all types of artifacts.   I followed details available on FlexMojos 6.0 wiki page and its child page specifically for migrating to FlexMojos 6.

1. Upgrade to Maven 3.0.5 (required for FM6)
2. Changed the FlexMojos version property in my parent pom file to 6.0.1
3. Changed the group id for the FlexMojos plugin from org.sontaype.flexmojos to net.flexmojos.oss
4. Update the playerglobal dependency 
1. Group ID = com.adobe.flash.framework
2. Artifact ID = playerglobal
3. Remove version that points to Flex SDK
4. Update classifier tags to version

Once I made these small changes I was up and running with the new improved FlexMojos 6.0.1.  After that I moved on to the bigger task of Apache Flex 4.13.  I downloaded the Apache Flex installer and installed the SDK locally and then used the Apache Flex mavenizer, lots of details on that in the Apache Flex Wiki. I won't go into details, but I basically downloaded the source for the project and build the maven deployer.  Since I wanted to test locally I did modify the deployer slightly so it would just install the artifacts to my local repository first.  Overall it was pretty straightforward.

Next I updated my various pom files for FlexMojos 7.0.1 and Apache Flex 4.13.  Here are the steps:

1. Update the flexmojo.version property in the root pom to 7.0.1
2. Update the flex sdk version property in the root pom to 4.13.0.20140701
3. Updated the old groupID of com.adobe.flex to org.apache.flex for several dependencies.  In my case there were some instances where the old group id was valid because I had some automation libraries that I still don't have artifacts for and also for some exclusions.
4. Remove the license jar dependency.
5. Updated the flexframework artifact name to framework and fixed the group id for it to org.apache.flex
6. Updated the theme dependency so it doesn't have a classifier and instead of the type being css it is now swc.
7. Updated the theme dependency's group id to org.apache.flex.framework.themes
8. Updated all the Flex dependencies from the scope of "caching" to "rsl", because there aren't any swz files for Apache Flex libraries
9. Updated the group id for all automation libraries to org.apache.flex.framework.automation
10. Remove the "_rb" from the automation artifact names and added a new classifier of ".rb"

All of the above changes got me 99% of the way there and I was able to build the project successfully with Maven, unfortunately I ended up with a runtime problem.

When loading the application in a browser I received the dreaded VerifyError 1053 "invalid override of the removeItem() method.  As it turns out the third party library I was using had a removeItem() method on a class that extended from ListCollectionView AND in the same method was added to Apache Flex 4.10.  

Of course I didn't just take the error message at its face value and spent a few days trying to figure out the problem.  Once I did it was just a matter of downloading the source for the specific version of the third party library, changing the name of the method, rebuilding a "new" version and deploying it to my maven repository.  Of course if I didn't have access to the source I would have been in trouble. After that the application behaved as it did before the upgrade.