I'm not so sure using the OEM API would really be that much of a shortcut, because - as I described - you would have to wrap every single option. By using the CLI you can wrap only those options that are much needed and allow the user to still pass additional options as command line flags.
On Wed, Nov 21, 2012 at 12:37 PM, christofer.d...@c-ware.de < christofer.d...@c-ware.de> wrote: > Hi Max, > > thanks for that input. Hmmm ... I think I'll have a little more detailed > look at how it's done in Flexmojos. I think the option of calling the > Components in the mxmlc and compc jar files directly should allow some > intelligent solution. But does the Oem-Compiler API change that often? As > Apache is now in charge of that lib I think it should be a manageable task > to maintain this. I remember form a POC of a Flex Cocoon Serializer I did 4 > Years ago, that the Compiler was really a spaghetti-code monster that was > certainly no fun in finding out how to use. > > So eventually it would be a solution to get results pretty fast to build a > first version using the OEM-compiler and to replace that with a different > implementation if this provides major benefits over the OEM-compiler. > > I think the biggest task is to get an initial working version ready and > the Compiler Mojo will definitely be the most tricky one. I guess the > OEM-compiler would be a valid shortcut and as it doesn't prevent us from > implementing alternatives, I think I'll go that road. The lack of > documentation is unfortunate, but I'm sort of used to the fact that stuff > isn't documented and usually for me the source-code is the documentation I > use most anyway ;-) > > Unfortunately I don't know of any benchmarks :-( > > Chris > > > -----Ursprüngliche Nachricht----- > Von: Maxime Cowez [mailto:maxime.co...@gmail.com] > Gesendet: Mittwoch, 21. November 2012 10:51 > An: flex-dev@incubator.apache.org > Cc: Yennick Trevels > Betreff: Re: Who's a flex compiler-configuration pro on this list? > > Hi Christofer, > > I've been discussing this topic with Yennick, the creator of GradleFx. > When faced with the decision on how to wrap the compiler he opted against > the use of the OEM API for the following reasons (some of which are > specific to GradleFx, but others may apply to your situation as well, so I > decided to share this information): > > [Maintenance] > The general gist here is that not many people are working on GradleFx and > those who do are doing it on their own time, so we need a pragmatic > approach. > - By using the API each and every compiler option must be wrapped > programmatically and exposed through a "convention property" (that's Gradle > lingo for a configuration setting). A lot more code would be required to > achieve this. By using the ANT task and exposing an > "additionalCompilerOptions" convention property, we allow the user to pass > in whatever exotic options he requires. > - When a new version of the SDK/compiler is released, possibly with new > compiler options, GradleFx' own API would have to be updated. This is not > necessary with the ANT approach, since the "additionalCompilerOptions" > convention property allows users to use the new options right away; no > update required. > - Overall code complexity would be higher, which might deter possible > contributors. > - Maintaining backwards compatibility with different versions of the OEM > API would soon become a pain in the ass. > > [Flexibility] > - New versions of Flex are immediately usable through an older version of > GradleFx (cf. Maintenance#2) > - The user has complete control and does not depend on what we decide to > expose through GradleFx's API; it's not a magic box. > > [Stability] > Passing the options through the command line interface is very safe and > greatly limits the amount of errors, because all the nitty-gritty is > already handled in there. Apparently FlexMojos, which depends on the OEM > API, can sometimes throw unexplainable errors to which even FlexMojos' > developers (don't know if that was you ;) ) could find an answer. > > [Documentation] > Documentation is sparse to say the least. I suppose your question here > proves that point. > > So to sum it up, Yennick decided to trade some performance for all of the > above. Also because one does not build all the time: a CI server doesn't > mind waiting a little longer and I suppose a developer would mostly compile > intermediate builds through his IDE. > > I hope this sheds some light on the decisions you have to make. > BTW: Do you know of any preformance benchmarks which pit the OEM API > against the command line interface? I sure would like to have an idea of > how big that performance improvement really is. > > Cheers, > Max > > > > On Tue, Nov 20, 2012 at 10:53 PM, Gordon Smith <gosm...@adobe.com> wrote: > > > Although I'm knowledgeable about the new Falcon compiler, I'm not > > particularly knowledgable about the OEM API for the old compiler. > > (Falcon discontinued this API.) But my first googling brought up this > link: > > > > http://livedocs.adobe.com/flex/3/compilerAPI_flex3.pdf > > > > Are you aware of this document? > > > > - Gordon > > > > > > -----Original Message----- > > From: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] > > Sent: Tuesday, November 20, 2012 3:27 AM > > To: flex-dev@incubator.apache.org > > Subject: AW: Who's a flex compiler-configuration pro on this list? > > > > Well ... glad to help :-) > > > > I was just assuming that because the oem-compiler is part of Flex, > > that in the Flex group there would probably be some people that have > > experience with that and could give me a hand with the ideal way of > using it. > > > > After all ... the resulting plugin should be as performant as possible > > and as I'm starting to work on something completely new I can build > > the basic design around that ideal usage pattern. > > Changing this afterwards will definitely be more work. > > > > > > Chris > > > > > > -----Ursprüngliche Nachricht----- > > Von: Maxime Cowez [mailto:maxime.co...@gmail.com] > > Gesendet: Dienstag, 20. November 2012 12:13 > > An: flex-dev@incubator.apache.org > > Betreff: Re: Who's a flex compiler-configuration pro on this list? > > > > So now you're helping us instead of the other way around ;) I'm > > definitely going to take a look at that. > > I suppose another advantage would be better control over logging, > > because at the moment we're limited to whatever the ANT task puts on > > the output stream. > > > > > > On Tue, Nov 20, 2012 at 11:45 AM, christofer.d...@c-ware.de < > > christofer.d...@c-ware.de> wrote: > > > > > Here's a link to that API: > > > http://livedocs.adobe.com/flex/3/compilerAPI_flex3.pdf > > > > > > I guess the main advantage was that you were able to load the > > > compiler once and reuse that instance throughout your build. This > > > dramatically reduced the build time, because the compiler didn't > > > have to load up to > > > 3 times (Main, Test, ASDoc) for every Maven module. > > > > > > Chris > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] > > > Gesendet: Dienstag, 20. November 2012 11:43 > > > An: flex-dev@incubator.apache.org > > > Betreff: AW: Who's a flex compiler-configuration pro on this list? > > > > > > Hmmm I think this is the way Flexmojos used to work in the old days, > > > but has since switched to using the oem-compiler thingy ... don't > > > 100% understand what that is into all details, but as far as I > > > understand, it's an API for directly communicating with the Compiler > > > mainly used by OEMs for creating IDEs and Tools utilizing Flex. > > > > > > I recall this had a great performance improvement over the > > > command-line wrapping solution, so this is more the way I am going > > > to > > choose. Anyway ... > > > the compiler is Java and so I would like to instantiate it and > > > communicate with it directly using some pre-defined API. > > > > > > Chris > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Maxime Cowez [mailto:maxime.co...@gmail.com] > > > Gesendet: Dienstag, 20. November 2012 11:35 > > > An: flex-dev@incubator.apache.org; Yennick Trevels > > > Betreff: Re: Who's a flex compiler-configuration pro on this list? > > > > > > Hi Christofer, > > > > > > I would certainly not claim to be an expert in the matter, but I > > > have gathered quite some knowledge by contributing to GradleFx ( > > > http://gradlefx.org/). Much like FlexMojos is a Maven plugin for > > > compiling Flex apps, GradleFx is a Gradle (http://gradle.org/) > > > plugin to achieve the same goal. > > > > > > It's open-source, so you're welcome to take a look at how we > > > implemented things. I guess you would especially be interested in > > > the org.gradlefx.cli package ( > > > https://github.com/GradleFx/GradleFx/tree/master/src/main/groovy/org > > > /g > > > radlefx/cli > > > ). > > > We used Gradle's built-in ANT task executor to execute the compile > > > command through Flex's own ANT task. > > > > > > The CommandLine Interface wrapping is fairly complete, but there are > > > two things still missing: > > > - module support (see > > > https://github.com/GradleFx/GradleFx/issues/46) > > > - full AIR/mobile support (only partially implemented, also see > > > https://github.com/GradleFx/GradleFx/issues/25) > > > > > > Feel free to ask questions if you think we can be of assistance. > > > > > > Cheers, > > > Max > > > > > > > > > On Tue, Nov 20, 2012 at 9:11 AM, christofer.d...@c-ware.de < > > > christofer.d...@c-ware.de> wrote: > > > > > > > Hi, > > > > > > > > As I mentioned in the "welcome" mail. My primary goal is to create > > > > a maven plugin for compiling flex/air applications using maven. > > > > Now in Flexmojos the compiler mojo is the biggest beast and also > > > > that having to deal with all the legacy stuff. Therefore I didn't > > > > want to be to "inspired" by the Flexmojos counterpart, and thought > > > > that someone here on the list could eventually be really fit in > > > > how to use the compiler(s) programmatically (Without whipping up > > > > the content of a commandline call and executing that using exec). > > > > > > > > I know there seem to be multiple ways to remote control the > > > > compiler, unfortunately I don't quite know which approach is best. > > > > > > > > So any input here greatly appreciated :) > > > > > > > > Chris > > > > > > > > > > > > > >
