Well I already started down a different path. A short while ago I discovered something: Velo initialy created a FlexCompiler interface which defines methods for swf, swc, asdoc etc. Initially there was only one implementing class (DefaultCompiler) which was directly linked to the old compiler. I now implemented a second implementing class (FalconCompiler) which is directly linked to the Falcon compiler internals. All I needed now, is to insert one more layer of abstraction. For this I cereated a factory to return a compiler instance depending on the configuration. It won't be able to auto-detect the compiler type but, by setting "compilerToUse=falcon" it should work. I know this is not too pretty, but I guess it should to the trick. We can do "pretty" after "works" is done ;-)
Chris PS: And it should be prettier than hacking some classes :-) -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Donnerstag, 31. Juli 2014 17:43 An: dev@flex.apache.org Betreff: Re: AW: Flexmojos using Falcon It appears that Flash Builder loads the flex-oem-compiler.jar from the SDK lib folder. Is it really impractical to abstract what classes Flexmojos uses? Falcon's flex-oem-compiler.jar is quite a hack, blending old MXMLC classes and wiring them to Falcon classes. But that's because I can't change FlashBuilder. -Alex On 7/31/14 7:27 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >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.d...@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
