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
