flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject How to deal with Falcon/CompC FDKs?
Date Fri, 11 Apr 2014 16:18:25 GMT

I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems
to be running fine :)

Now I had the problem, that currently it would be possible to have two variants of mavenized
compiler in the FDK. So how should web e able to distinguish between both?

If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon,
I guess this would be a problem, as including compiler-falcon in the maven config wouldn't
override the compiler version that is included per default. So If Flexmojos was built against
4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12
and compiler-falcon-4.13, which could be really bad.

Another option would be to add classifiers: so the falcon and the compc version would both
be called compiler, but one would have the cclassifier "compc" and one would be "falcon".
Then the Override mechanism would work. I would then make Flexmojos use "compc" as defaullt
and we should have a minimal impact on that. Unfortunately classifiers can't be used for this
as if you have mmultiple artifacts with different classifiers, they still share the same pom
and classifiers seem to be not availablle for pom-modules.

One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to
create a jar artifact, that contains all the jars content of all the dependencies of the pom,
but I think this is pretty ugly :(

So I would have another proposal:
How would it be to keep the compiler the way it was allways done including compc and mxml
and to add another pom that contains falcon and to change Flexmojos to check for falcon and
as soon as that's availallbe it would use that, if not it would use the default. Now we would
have MXML, CompC and Falcon in the build path but from a maven perspective this would be the
cleanest solution.

What do you think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message