You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2014/07/30 21:33:13 UTC

Flexmojos using Falcon

Hi,

so my changes to the falcon build script were actually quite simple. Now I have an artifact "org.apache.flex.compiler:falcon-compiler:0.0.2-SNAPSHOT in my local repo which pulls in all dependencies of the compiler using maven (Yes ... it's only one jar we seem to have to provide).

Now I'm doing my first steps with Flexmojos using Falcon and I noticed something that I have to change:
Till now Flexmojos always referenced a default compiler version. So if you didn't provide an explicit version, it used the one Flexmojos was built against. Now starting with falcon we have different compiler artifacts and here the simple "version overriding" of maven no longer works. So I was thinking about setting that dependency to "provided", so the user has to provide a compiler artifact. The downside is that you have to provide something you didn't have to earlier. The good thing is that this way you can choose your compiler artifact. Eventually I might even be able to bring back together the Adobe and Apache versions of flex so Flexmojos could build both worlds (but that would be a goodie, that I'll experiment on as soon as Falcon is working).

So keep your fingers crossed that we will be able to build flex applications with falcon using flexmojos. If we get the build script running on the Apache jenkins we could even get "4.14.0-SNAPSHOT" sdks out the door automatically, which would make bleeding-edge experimenting a lot easier :)

Chris

AW: Flexmojos using Falcon

Posted by Christofer Dutz <ch...@c-ware.de>.
Ok ... so I have followed this path all day now and I sort of feel like walking into a dark and spooky forrest the longer I go ;-)

Simply switching the compiler artifact will probably not do the trick. Even if for FlashBuilder falcon seems to be a drop-in-replacement, for Flexmojos it's not. A lot of internal clases have been used by Velo in the inner workings of Flexmojos. For example in order to trigger a compile he calls the static "mxmlc" method inside the flex2.tools.Mxmlc class. So how does flashbuilder do this? Does it check the MANIFEST.MF file in a jar called compc.jar and mxmlc.jar to know which classes it should use? Having a look at the flex-compiler-oem jar sort of seems that it's quite tightly coupled to the old packages and Classes. 

So how does the FlashBuilder do it? I would like to do it the same way for Flexmojos.

Chris

-----Ursprüngliche Nachricht-----
Von: Christofer Dutz [mailto:christofer.dutz@c-ware.de] 
Gesendet: Mittwoch, 30. Juli 2014 21:33
An: 'dev@flex.apache.org'
Betreff: Flexmojos using Falcon

Hi,

so my changes to the falcon build script were actually quite simple. Now I have an artifact "org.apache.flex.compiler:falcon-compiler:0.0.2-SNAPSHOT in my local repo which pulls in all dependencies of the compiler using maven (Yes ... it's only one jar we seem to have to provide).

Now I'm doing my first steps with Flexmojos using Falcon and I noticed something that I have to change:
Till now Flexmojos always referenced a default compiler version. So if you didn't provide an explicit version, it used the one Flexmojos was built against. Now starting with falcon we have different compiler artifacts and here the simple "version overriding" of maven no longer works. So I was thinking about setting that dependency to "provided", so the user has to provide a compiler artifact. The downside is that you have to provide something you didn't have to earlier. The good thing is that this way you can choose your compiler artifact. Eventually I might even be able to bring back together the Adobe and Apache versions of flex so Flexmojos could build both worlds (but that would be a goodie, that I'll experiment on as soon as Falcon is working).

So keep your fingers crossed that we will be able to build flex applications with falcon using flexmojos. If we get the build script running on the Apache jenkins we could even get "4.14.0-SNAPSHOT" sdks out the door automatically, which would make bleeding-edge experimenting a lot easier :)

Chris