FormItem Column Count Issue

I ran into a problem today when loading a Form component with a couple of FormItem children.  The error message said, “The Form must have form items with the same number of constraint columns”. In an effort to hopefully save somebody time in the future, here is the reason this showed up.  

One of my FormItem children had a skinclass defined on it, and the other didn’t. The default skinclass provides three content columns (main content, sequence content and help content), while the other FormItem’s custom skinclass only had two. When attempting to find the max width for each form item in a form it keeps track to make sure that all the FormItems have the same number of “content columns”. If not the error will be thrown.

So to fix it I just had to make sure that every FormItem in the Form was using the same skinClass.

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.