incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: Who's a flex compiler-configuration pro on this list?
Date Wed, 21 Nov 2012 20:24:30 GMT
Hi Alex,

Well I was thinking on implementing this for mxmlc compilers first in order to have a fully
functional plugin and then to add support for falcon as soon as it supports 100% of flex (Or
am I wrong in the assumption that Falcon is not yet being a 100% replacement?). If Falcon
is going to be finished soon, perhaps going the Falcon way might even be the better solution.
Especially because of me being able to get real support from you ;-)

Chris






-----Ursprüngliche Nachricht-----
Von: Alex Harui [mailto:aharui@adobe.com] 
Gesendet: Mittwoch, 21. November 2012 18:27
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?

Chris, are you planning to do your mojo on Falcon or the old MXMLC code?
Hopefully Falcon.  And while it may not have the APIs you may need right now, I think we can
make it work for you.

FlashBuilder and other IDEs and some other configurations tried to leverage as much saved
state from previous and existing compiles.  IIRC, it tried to cache information about the
compilation unit so it could incrementally compile only changed areas of code in the file,
and tried to save SWC information it had read so it could be applied to other SWFs in a multi-swf
build. I think we can probably do that in Falcon.  Even the linker should be smart about SWF
symbols it has created

-Alex

On 11/21/12 6:16 AM, "Carol Frampton" <cframpto@adobe.com> wrote:

> I'm could be wrong but I'm sure this API was orginally done so that 
> FlashBuilder could integrate with Flex.  The api was then "documented" 
> in a minimal way so others could use it.
> 
> Carol
> 
> On 11/20/12 4 :53PM, "Gordon Smith" <gosmith@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.dutz@c-ware.de [mailto:christofer.dutz@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.cowez@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.dutz@c-ware.de < 
>> christofer.dutz@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.dutz@c-ware.de [mailto:christofer.dutz@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.cowez@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.dutz@c-ware.de < 
>>> christofer.dutz@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
>>>> 
>>>> 
>>> 
> 

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message