[Falcon][FlexJS] Summary of the Maven migration

[Christofer Dutz <ch...@c-ware.de>]

Hi,


as there were several questions by different people in multiple threads, I'll try to aggregate the answers.


The current Falcon build requires some (normal) FlexSDK components (spark.swc, framework.swc, ...) as well as some Flash components (playerglobal.swc) the FlexASJS build also requires Air components (airglobal.swc). These have to be provided as Maven artifacts. Unfortunately the FlexSDK as well as the Adobe parts are not available as Maven artifacts.


For this I built the flex-sdk-converter which is able to hook itself into Maven as an extension and in case of needing any of these non-Maven artifacts, it downloads the SDK binary distributions unpacks them and converts their content into Maven artifacts. This all happens transparently to the Maven build.


But in order to do its magic this Maven extension needs to be loaded. The old option was to download the extension and copy it to the "${MAVEN_HOME}/lib/ext" directory. Since Maven 3.3.1 maven also looks into an ".mvn/extensions.xml" file (Which is relative to the directory the maven command is issued, not relative to the root pom.xml). This is the reason for requiring Maven 3.3.1. If you provide the needed artifacts 3.1.1 should also work. If not you would simply get errors from maven about not being able to resolve some of the dependencies. As seeing if the extension is operational was almost impossible, I made it output an Ascii-Art Flex logo on the command-line. So if you see that, the flex-sdk-converter is in place.


Now the next thing is that per default Maven looks in Maven Central for artifacts. All released Apache stuff released as Maven artifacts automatically goes there. Unfortunately SNAPSHOTS don't and we haven't released the flex-sdk-converter yet. In Maven you can provide additional Repositories to look for in the pom.xml so in general resolving of SNAPSHOT versions shouldn't be a problem. The problem is that Maven Extensions from the ".mvn/extensions.xml" are resolved before Maven starts to read the root pom.xml. Therefore we can't tell it where to get the flex-sdk-converter from. That's were the "-s settings-template.xml" comes in. In Maven there is a ".m2/settings.xml" which Maven looks for per default. If it's there this is used automatically. If you just installed/unpacked Maven, you will probably not have this file and Maven will stick to the defaults. In this file you can define further repositories which maven would look at. To make things simpler for you guys I wrote the "settings-template.xml" which contains all that is needed to use the flex-sdk-converter. You can copy this file into the ".m2" directory in your User-Home and name it "settings.xml" of you tell maven which settings.xml it should use. That's what the "-s settings.xml" is for.


Now to the last part of confusion: Why do we need to run 3 maven builds to build the falcon part?

Falcon is a pretty hefty mix of stuff with a lot of cyclic dependencies. So you need to build some parts in order to build others. While maven has no problem with this for normal dependencies, it is a problem if plugins in the build need other parts. In our case we need the flexjs-maven-plugin to build the externs and that needs the compiler ... both initially don't exist and therefore Maven will complain and die. I categorized the modules and found 3 partitions:

- Utils: This contains the flexjs-maven-plugin (The Maven plugin to build FlexJS applications), compiler-build-tools (Little helpers to annotate generated code, mainpulate code etc.), compiler-jburg-types (Contains only one class that JBurg needs to generate code)

- Compiler: compiler, compiler-jx, debugger, flex-compiler-oem (These contain all the parts of the compiler itself)

- Externs: All the extern modules which are built using the compiler and the maven plugin.

In order to support this I created 3 Maven profiles "utils", "compiler" and "externs". Each profile is activated by the "-P {profileName}".

I know this is not ideal but it's only temporary. The compiler-build-tools, and the compiler-jburg-types will not change much and as soon as they are released once, so I would opt for simply referencing the released versions and re-releasing them as soon as they are needed. The maven plugin will be moved to a separate git repo. Therefore the "utils" profile will not be needed anymore. I think in the end I will also be able to resolve the cycle between compiler and externs. In the end building should be as easy as "mvn clean install".


Hope that explains things a little better [😊]


And now I hope I'll manage to cross the finishing lines ... 4 examples to go ...


Chris