Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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

Re: Who's a flex compiler-configuration pro on this list?

[Maxime Cowez <ma...@gmail.com>]

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.dutz@c-ware.de <
christofer.dutz@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.cowez@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 <go...@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
> > > >
> > > >
> > >
> >
>

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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.cowez@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 <go...@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
> > >
> > >
> >
>

Re: Who's a flex compiler-configuration pro on this list?

[Yennick Trevels <ye...@gmail.com>]

One small correction though, in GradleFx we don't use the compc and mxmlc
Ant tasks(provided by flexTasks.tasks in the SDK), but we call the
compc.jar and mxmlc.jar files with Ant and we provide them the compiler
options as you would by using the command line.


On Wed, Nov 21, 2012 at 10:51 AM, Maxime Cowez <ma...@gmail.com>wrote:

> 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 <go...@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
>> > >
>> > >
>> >
>>
>
>

Re: Who's a flex compiler-configuration pro on this list?

[Maxime Cowez <ma...@gmail.com>]

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 <go...@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
> > >
> > >
> >
>

AW: AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

Buuuuuut ... thinking of it :-) 

Mabe it would indeed be better to start with Falcon as this is definitely the future of Flex and Flexmojos already lets you build using MXMLC ... And I always wanted to start digging into it, but never actually found a usecase for it.
And as I posted yesterday evening ... having a local-guru around would definitely make things easier :-)

@Alex: Perhaps if Adobe were to publish the playerglobal and the airglobal (Don't need the runtime ... think mavenizing the Runtime is too much ... would simply use the runtimes from PATH).
Without those TWO swc-artifacts the final solution would always be half-baked (No matter what compiler) as no user could: "simply add the plugin and start coding flex". A user would always have to manually install the artifacts.
So what do you think? You make the one thing happen, and I'll do the second? ;-)

Chris




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




On 11/21/12 12:24 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> 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
Well, we have a bunches of patches, fixed bugs and some new locales that I think we should release soon, and I don't see us getting Falcon ready in that timeframe.

However, I will be spending as much time as I can on Falcon otherwise, and Gordon knows the Falcon code better than MXMLC.  And I think you'll find the code easier to work with.

So if you want to get the basics of your work done for this next release (it might not happen until late December or January) via MXMLC that's fine, but I would definitely recommend saving optimization work for Falcon.

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

AW: AW: AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

I think this was what Velo was refering to as "FlexMojos Enterprize", his commercial Branch of FM.
But I agree, when starting from scratch, we should do it the right way so all the mobile stuff can be done too.

Chris



-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com] 
Gesendet: Samstag, 24. November 2012 18:08
An: flex-dev@incubator.apache.org
Betreff: Re: AW: AW: Who's a flex compiler-configuration pro on this list?

Hi,

@Chris, After a quick look at FM6, I realized that it use AIRPackager instead of a direct call to ADT Class (4.6.0.x), so no target option (the type of package to create) can be append and then no mobile native application can be generated except for AIR packaging.

I guess, with a bit of effort, it would be possible to replace the FlexmojosAIRPackager to use ADT instead of AIRPackager and then be able  to generate every kind of packaging, what do you thing about ?

- Fred.

-----Message d'origine-----
From: christofer.dutz@c-ware.de
Sent: Friday, November 23, 2012 1:45 PM
To: flex-dev@incubator.apache.org
Subject: AW: AW: Who's a flex compiler-configuration pro on this list?

Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc and in the Flexmojos Testsuite there are tests for the different Air features and I am not having any trouble with that.
The only thing is that I do have to provide the same third party libs the Flex SDK needs to have provided. So if you are talking about these libs, you might be correct.
But It would already be a great improvement to be able to build Flex applications without manual intervention.
I have to admit that I have never ever done any Air yet nor any of the Flex guys around here that I have worked with.

Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just that for those not using it this would be a great improvement.

Chris

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




On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> Buuuuuut ... thinking of it :-)
>
> Mabe it would indeed be better to start with Falcon as this is 
> definitely the future of Flex and Flexmojos already lets you build 
> using MXMLC ... And I always wanted to start digging into it, but 
> never actually found a usecase for it.
>
> @Alex: Perhaps if Adobe were to publish the playerglobal and the 
> airglobal (Don't need the runtime ... think mavenizing the Runtim is 
> too much ... would simply use the runtimes from PATH).
> Without those TWO artifacts the final solution would always be 
> half-baked (No matter what compiler) as no user could: "simply add the 
> plugin and start coding flex" :-) So what do you think? You make the 
> one thing happen, and I'll do the second?
> ;-)
>
I need convincing that this will work for captive runtime for mobile apps, and not sure how you are supposed to get the other executables that help make up the AIR package.

But if you want to try prototyping it, feel free.  I wll try to find time to help next week, if you need help.  I want to make sure it will work before we go ask for approvals.

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

Re: AW: AW: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

Hi,

@Chris, After a quick look at FM6, I realized that it use AIRPackager 
instead of a direct call to ADT Class (4.6.0.x), so no target option (the 
type of package to create) can be append and then no mobile native 
application can be generated except for AIR packaging.

I guess, with a bit of effort, it would be possible to replace the 
FlexmojosAIRPackager to use ADT instead of AIRPackager and then be able  to 
generate every kind of packaging, what do you thing about ?

- Fred.

-----Message d'origine----- 
From: christofer.dutz@c-ware.de
Sent: Friday, November 23, 2012 1:45 PM
To: flex-dev@incubator.apache.org
Subject: AW: AW: Who's a flex compiler-configuration pro on this list?

Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc and 
in the Flexmojos Testsuite there are tests for the different Air features 
and I am not having any trouble with that.
The only thing is that I do have to provide the same third party libs the 
Flex SDK needs to have provided. So if you are talking about these libs, you 
might be correct.
But It would already be a great improvement to be able to build Flex 
applications without manual intervention.
I have to admit that I have never ever done any Air yet nor any of the Flex 
guys around here that I have worked with.

Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just that 
for those not using it this would be a great improvement.

Chris

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




On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> Buuuuuut ... thinking of it :-)
>
> Mabe it would indeed be better to start with Falcon as this is
> definitely the future of Flex and Flexmojos already lets you build
> using MXMLC ... And I always wanted to start digging into it, but
> never actually found a usecase for it.
>
> @Alex: Perhaps if Adobe were to publish the playerglobal and the
> airglobal (Don't need the runtime ... think mavenizing the Runtim is
> too much ... would simply use the runtimes from PATH).
> Without those TWO artifacts the final solution would always be
> half-baked (No matter what compiler) as no user could: "simply add the
> plugin and start coding flex" :-) So what do you think? You make the
> one thing happen, and I'll do the second?
> ;-)
>
I need convincing that this will work for captive runtime for mobile apps, 
and not sure how you are supposed to get the other executables that help 
make up the AIR package.

But if you want to try prototyping it, feel free.  I wll try to find time to 
help next week, if you need help.  I want to make sure it will work before 
we go ask for approvals.

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>If you look in an AIR SDK, there are lots of files in there.  Sure you 
>might
only need to call adt.jar, but if you delete every other file in there
besides airglobal.swc, will you really get a valid AIR, AIRI, APK and
especially IPA?  I mean, the AIR runtime has to get processed into the IPA
right?  And the updater UI swfs in other packages?
And, I would still worry that adt.jar has some dependency


The adt.jar is completely autonomous, it contains the code for Air, llvm, 
uck, pki, rsa, png, nai, ipa, apk, and some android stufs too.



>If you are pretty sure no other files are needed, let's actually try it.
Try using your mavenizer on a stripped down AIR SDK with only airglobal.swc
and adt.jar and see if you can create an IPA via maven.  Or I will put up a
couple of versions of those two files on a server somewhere and those of you
who use Maven can try to see if they can switch between them.


As I mentioned it before, It's not possible, at the moment, with flexmojos, 
to generate anything else than AIR (that because is not relies on the 
ADT.class but on the Air subpart, the AIRPackager), but, with a bit of 
effort, I'm pretty sure it's possible the extend it to make it use the 
ADT.class which can generate everything.


- Fred.


-----Message d'origine----- 
From: Frédéric THOMAS
Sent: Sunday, November 25, 2012 6:28 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?

>I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer.  My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo.  Please correct me if
that is not true.  I'm still trying to learn all of this stuff.


For every AIR/Flex SDKs from a given directory structure, the mavenizer
compiles, zip, renames, re-organizes the entries
- For the compiler jars and the framework swc, it renames the files, create
a pom.xml and re-organize them in a final directory structure.
- For the themes, if a it's a swc, that's like above, if it's not, it
compiles it and do like above.
- Creates the sources and the config zips and then like above
- Create the pom.xml aggregators for the air-framework, the air
common-framework, flex common-framework and the flex-air common-framework
(and maybe I forgot something, it's late)


The mavenizer replace at the moment the lack of public repositories, even if
it's good enough for individuals and small companies, it is not for big
ones.


If Adobe and Apache decide to finaly host and deploy these frameworks in a
maven repository, they will have to mavenized them and the mavenizer is THE
TOOL for.


>Also, Apache Flex is trying to break any tie between the Apache Flex SDK 
>and
an AIR SDK.  Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.


You right, but like in current the SDK, there's a default FP/AIR that you
can change with few efforts, it's the same with the mavenized one.


>So, with my limited understanding of Maven, the goal was to have Apache 
>Flex
releases have a pom.xml and live in the Apache Maven repo, and have Adobe
playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
server


Yes, you're right, it's just that for Air, the entire sdk is needed.


>and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.


If all the SDKs become mavenized and hosted on public repositories, the only
use of the mavenizer gonna be to create those SDKs and push them to these
public repositories and preferably done by the companies who own these SDKs.


>Thanks for being patient.  I'm still coming up to speed on this stuff.

Welcome :)


- Fred.

-----Message d'origine----- 
From: Alex Harui
Sent: Sunday, November 25, 2012 5:15 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 5:16 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


>
> Switching SDK, is as easy as changing a property in only one pom.xml,
> nothing else to do as soon as the SDK you want to use is mavenized
> obviously, the player itself is not needed, we can specify the target
> version but there's no dependencies.
> During the SDK mavenization process (with the mavenizer), a relation 
> between
> Flex SDK and Air SDK is etablished, it's done by comparing the checksum of
> the airglobal.swc inside each Air SDKs and the ones inside each Flex SDKs.
I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer.  My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo.  Please correct me if
that is not true.  I'm still trying to learn all of this stuff.

Also, Apache Flex is trying to break any tie between the Apache Flex SDK and
an AIR SDK.  Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.

So, with my limited understanding of Maven, the goal was to have Apache Flex
releases have a pom.xml and live in the Apache Maven repo, and have Adobe
playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
server, and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.

Or will there still be a mavenizer that needs to be run?  If so, what will
it do?
>
>> but when building a .AIR file (and or an AIRI for signing) or a mobile
>> package,
> I'm pretty sure other parts of the AIR SDK are involved and that they 
> might
> change between AIR versions.
>
> AFAIK, airglobal.swc and ADT only are needed for packaging into AIR, AIRI,
> ANE, EXE, APK, IPA, ..., at the moment FlexMojos uses a class of the 
> adt.jar
> called AIRPackager and call the createAIR method instead of using the ADT
> class, therefore it can package only  into AIR (which is already something
> appreciated).
If you look in an AIR SDK, there are lots of files in there.  Sure you might
only need to call adt.jar, but if you delete every other file in there
besides airglobal.swc, will you really get a valid AIR, AIRI, APK and
especially IPA?  I mean, the AIR runtime has to get processed into the IPA
right?  And the updater UI swfs in other packages?

And, I would still worry that adt.jar has some dependency

If you are pretty sure no other files are needed, let's actually try it.
Try using your mavenizer on a stripped down AIR SDK with only airglobal.swc
and adt.jar and see if you can create an IPA via maven.  Or I will put up a
couple of versions of those two files on a server somewhere and those of you
who use Maven can try to see if they can switch between them.
>
> Not sure I anwsered at everything you want, only the things I understood 
> you
> want, ask again please for more precisions.

Thanks for being patient.  I'm still coming up to speed on this stuff.

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

Re: Who's a flex compiler-configuration pro on this list?

[Jeffry Houser <je...@dot-com-it.com>]

On 11/26/2012 4:55 AM, Frédéric THOMAS wrote:
>
> Are this big companies really not using anything that doesn't have an 
> open
> license? 

  Interesting note about this; the default contract for one of my 
current clients was that they had to own all code I delivered for them.  
The wording was pretty explicit; and I pointed out that meant I would 
not be able to make use of any open source software, such as 
frameworks.  The project lead understood the implications right away, 
but it still took some work to get legal to carve out an exception.

  The company in question uses plenty of things that don't have an open 
license, though.  ( Windows and MacOS being two prime examples )

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/26/12 1:55 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:

>> Because when you go to the download page, you have to accept the licensing
> terms.  Maven doesn't have any support for forcing people to accept
> licenses.  One option available to us is to provide Adobe with a Maven
> plug-in that will force a licensing dialog (once per machine, I suppose).
> 
> 
> Yes, it could be a solution even if it's not really in the maven spririt,
> let me understand something as I'm really noob in legal stuffs like
> licenceing, spring and hibernate are widely used in the java word, mainly
> via maven, the both have a licence, an apache licence for one and a gnu
> lesser general public licence for the second, shouldn't force people to
> accept their licence ?
Apache and GPL are relatively open licenses.  The Adobe license is pretty
restrictive and Adobe legal feels like you need to acknowledge that.
> 
> 
> Are this big companies really not using anything that doesn't have an open
> license?
> 
> Yes, they do that with some artifacts but that's exeptions
How much would it limit our success if the AIR SDK is one of these
exceptions?
> 
> 
> - Fred
> 

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>Because when you go to the download page, you have to accept the licensing
terms.  Maven doesn't have any support for forcing people to accept
licenses.  One option available to us is to provide Adobe with a Maven
plug-in that will force a licensing dialog (once per machine, I suppose).


Yes, it could be a solution even if it's not really in the maven spririt, 
let me understand something as I'm really noob in legal stuffs like 
licenceing, spring and hibernate are widely used in the java word, mainly 
via maven, the both have a licence, an apache licence for one and a gnu 
lesser general public licence for the second, shouldn't force people to 
accept their licence ?


Are this big companies really not using anything that doesn't have an open
license?

Yes, they do that with some artifacts but that's exeptions


- Fred


-----Message d'origine----- 
From: Alex Harui
Sent: Monday, November 26, 2012 4:51 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 11:14 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> I guess no company use this kind of approach we use with the mavenizer,
> instead, they build their maven project, which generate eveything directly
> mavenized.
> A company may want to put some artifacts public without sources, that's a
> common use but for what there's in Adobe SDKs, that's already public in 
> some
> way, everyone can already download them, what would be the point to not 
> make
> them available as well via Maven ?
Because when you go to the download page, you have to accept the licensing
terms.  Maven doesn't have any support for forcing people to accept
licenses.  One option available to us is to provide Adobe with a Maven
plug-in that will force a licensing dialog (once per machine, I suppose).
>
>
>> Why is this not ok for big companies?
>
> For big companies, the common rule is to accept artifacts from few quite
> known public repositories only and if the artifacts are not in snapshot
> version, so, very far from what we propose via the mavenizer where they 
> will
> have to do things by hand.
I know it would be less desirable, but why can't we call the AIR SDK a build
tool?  Don't folks have to download and install a JDK and Maven itself?  Or
can Maven handle switching JDK versions?

Are this big companies really not using anything that doesn't have an open
license?

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

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/24/12 11:14 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> I guess no company use this kind of approach we use with the mavenizer,
> instead, they build their maven project, which generate eveything directly
> mavenized.
> A company may want to put some artifacts public without sources, that's a
> common use but for what there's in Adobe SDKs, that's already public in some
> way, everyone can already download them, what would be the point to not make
> them available as well via Maven ?
Because when you go to the download page, you have to accept the licensing
terms.  Maven doesn't have any support for forcing people to accept
licenses.  One option available to us is to provide Adobe with a Maven
plug-in that will force a licensing dialog (once per machine, I suppose).
> 
> 
>> Why is this not ok for big companies?
> 
> For big companies, the common rule is to accept artifacts from few quite
> known public repositories only and if the artifacts are not in snapshot
> version, so, very far from what we propose via the mavenizer where they will
> have to do things by hand.
I know it would be less desirable, but why can't we call the AIR SDK a build
tool?  Don't folks have to download and install a JDK and Maven itself?  Or
can Maven handle switching JDK versions?

Are this big companies really not using anything that doesn't have an open
license?

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.

I guess no company use this kind of approach we use with the mavenizer, 
instead, they build their maven project, which generate eveything directly 
mavenized.
A company may want to put some artifacts public without sources, that's a 
common use but for what there's in Adobe SDKs, that's already public in some 
way, everyone can already download them, what would be the point to not make 
them available as well via Maven ?


>Why is this not ok for big companies?

For big companies, the common rule is to accept artifacts from few quite 
known public repositories only and if the artifacts are not in snapshot 
version, so, very far from what we propose via the mavenizer where they will 
have to do things by hand.


>Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?

You gonna discuss that with Chris I suppose but, for me and the work 
experiences I've got, as Flex is an entreprise framework and as I told you, 
the rule in big company is to accept artifact from known public repositories 
only, if none of the Adobe SDKs become public, in my current knwoledge of 
the thing, we close the door to the big company to use flexmojos 6 (the only 
one that make use of the apache flex sdk), they will continue to use the old 
flexmojos which work with the previous versions of the mavenized SDKs but 
won't use the new one, maybe a futur flexmojos 7 which will deal only with 
the apache flex sdk and with no Air.
The only way, with flexmojos 6, to open the door to big companies, is to 
mavenize and make public the adobe sdks and the apache one.


>I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.

Me too actually, the airglobal.swc and the adt.jar is apparently everything 
needed, I don't know if the use of the updater, the file promized and the 
other classes from the Air sdk are very used, but I guess that comes in 
complement to the flex sdk, am I wrong ?


- Fred.


-----Message d'origine----- 
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even 
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is 
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

AW: AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

He said, that he is sort of discontinuing everything regarding FM ... the thing he did mention was that if he was offered a certain amount of money, hey would merge the stuff from FM Enterprize back to normal FM.

Currently I am not really deep into AIR. I think there is a lot to be done before being able to work on the mobile packaging and stuff like that. The thing I will start on in the next weeks will definitely be the Compiler. As I am really interested in Falcon and Falcon will be the new official compiler, I would probably start with a plugin supporting this. Unfortuneately I guess the Compiler will probably be 75% of the work of the entire plugin suite. So I guess there will be some time until we can start on the packaging.

As I mentioned before ... I did sort of delay a lot of my job-work while getting FM and the Mavenizer running. I have to first sattisfy the needs of some of my customers, or I'll be having some serious trouble ... so don't expect a 0.1-beta to soon ;-)


Chris



-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com] 
Gesendet: Sonntag, 25. November 2012 14:05
An: flex-dev@incubator.apache.org
Betreff: Re: AW: Who's a flex compiler-configuration pro on this list?

Hi,

Actually, reading you Chris, my 2.5 scenario, where adobe would deploy their sdks, is wrong (sorry @Alex, I had to think more about before talking).


> target 100% would be cooler, but 80% is better than 0%.


Yes, and that may evolve.


@Chris,
Am I wrong or I read somewhere Velo discontinued its Commercial Flexmojos 
Enterprize and now, he provides this feature case by case, being paid for 
that, re-integrating some changes in specific versions at demand only ?
Have you already thing about the ADT usage instead of the AIRPackager ?

- Fred

-----Message d'origine----- 
From: christofer.dutz@c-ware.de
Sent: Sunday, November 25, 2012 1:38 PM
To: flex-dev@incubator.apache.org
Subject: AW: Who's a flex compiler-configuration pro on this list?

Exactly.

Currently noone is providing the FDKs publically, because at least the 
dependencies to the two or three Adobe artifacts that are not available via 
Maven.
Even if only manually deploying these artifacts isn't such a show-stopper as 
having to deploy the entire FDK, I think most users are used not having to 
do anything at all and this would prevent a lot of maven newbes from using 
flex in maven. At least this is the impression I am having while servicing 
the Flexmojos Mailinglist. Most users are consumers and not willing to eaven 
read a README file (Think you probably noticed that problem when releasing 
the first Apache Flex)

I can see the following scenarios (each step going down the maven road even 
further):
1. Using the Mavenizer to locally deploy FDKs.
2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those 
artifacts in a public repo.
3. Building Flex with Maven, eliminating the need to use the Mavenizer all 
together.

I agree that there might be some issues with the native packaging and mobile 
deployment. This is currently only handled by Velos Commercial Flexmojos 
Enterprize and these features are not part of the normal FM currently. So I 
agree that there might be some issues with the build needing more artifacts. 
But I think with the two or three artifacts discussed in this thread, we 
should be albe to target about 80% of the normal users use-cases. Being able 
to target 100% would be cooler, but 80% is better than 0%.

Chris


-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Gesendet: Sonntag, 25. November 2012 08:59
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?

>
Christopher Dutz gave me the impression that all Adobe would have to do is 
place a pom.xml alongside each playerglobal.swc.  Is there more to it?

I guess the goal behind that is to be able to get those artefact from a 
legal repo, we can not legaly provide them from inside the mavenized apache 
flex sdk, I guess what Chris want to do, is to make our sdk public via the 
apache repo and get those last artifacts from adobe, doing so, if only the 
the apache flex sdk is publicly available, that should not be a problem for 
companies to host internaly the new structure of the new sdk and the old 
structure of the others, they could use fm<6 and fm 6 on different projects.
The only thing is they shouldn't have to use the mavenizer to convert the 
SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.

- Fred.

-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>I think this was what Velo was refering to as "FlexMojos Enterprize", his 
>commercial Branch of FM.
But I agree, when starting from scratch, we should do it the right way so 
all the mobile stuff can be done too.

Ok.

-----Message d'origine----- 
From: Frédéric THOMAS
Sent: Sunday, November 25, 2012 2:05 PM
To: flex-dev@incubator.apache.org
Subject: Re: AW: Who's a flex compiler-configuration pro on this list?

Hi,

Actually, reading you Chris, my 2.5 scenario, where adobe would deploy their
sdks, is wrong (sorry @Alex, I had to think more about before talking).


> target 100% would be cooler, but 80% is better than 0%.


Yes, and that may evolve.


@Chris,
Am I wrong or I read somewhere Velo discontinued its Commercial Flexmojos
Enterprize and now, he provides this feature case by case, being paid for
that, re-integrating some changes in specific versions at demand only ?
Have you already thing about the ADT usage instead of the AIRPackager ?

- Fred

-----Message d'origine----- 
From: christofer.dutz@c-ware.de
Sent: Sunday, November 25, 2012 1:38 PM
To: flex-dev@incubator.apache.org
Subject: AW: Who's a flex compiler-configuration pro on this list?

Exactly.

Currently noone is providing the FDKs publically, because at least the
dependencies to the two or three Adobe artifacts that are not available via
Maven.
Even if only manually deploying these artifacts isn't such a show-stopper as
having to deploy the entire FDK, I think most users are used not having to
do anything at all and this would prevent a lot of maven newbes from using
flex in maven. At least this is the impression I am having while servicing
the Flexmojos Mailinglist. Most users are consumers and not willing to eaven
read a README file (Think you probably noticed that problem when releasing
the first Apache Flex)

I can see the following scenarios (each step going down the maven road even
further):
1. Using the Mavenizer to locally deploy FDKs.
2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those
artifacts in a public repo.
3. Building Flex with Maven, eliminating the need to use the Mavenizer all
together.

I agree that there might be some issues with the native packaging and mobile
deployment. This is currently only handled by Velos Commercial Flexmojos
Enterprize and these features are not part of the normal FM currently. So I
agree that there might be some issues with the build needing more artifacts.
But I think with the two or three artifacts discussed in this thread, we
should be albe to target about 80% of the normal users use-cases. Being able
to target 100% would be cooler, but 80% is better than 0%.

Chris


-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Gesendet: Sonntag, 25. November 2012 08:59
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?

>
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?

I guess the goal behind that is to be able to get those artefact from a
legal repo, we can not legaly provide them from inside the mavenized apache
flex sdk, I guess what Chris want to do, is to make our sdk public via the
apache repo and get those last artifacts from adobe, doing so, if only the
the apache flex sdk is publicly available, that should not be a problem for
companies to host internaly the new structure of the new sdk and the old
structure of the others, they could use fm<6 and fm 6 on different projects.
The only thing is they shouldn't have to use the mavenizer to convert the
SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.

- Fred.

-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

Re: AW: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

Hi,

Actually, reading you Chris, my 2.5 scenario, where adobe would deploy their 
sdks, is wrong (sorry @Alex, I had to think more about before talking).


> target 100% would be cooler, but 80% is better than 0%.


Yes, and that may evolve.


@Chris,
Am I wrong or I read somewhere Velo discontinued its Commercial Flexmojos 
Enterprize and now, he provides this feature case by case, being paid for 
that, re-integrating some changes in specific versions at demand only ?
Have you already thing about the ADT usage instead of the AIRPackager ?

- Fred

-----Message d'origine----- 
From: christofer.dutz@c-ware.de
Sent: Sunday, November 25, 2012 1:38 PM
To: flex-dev@incubator.apache.org
Subject: AW: Who's a flex compiler-configuration pro on this list?

Exactly.

Currently noone is providing the FDKs publically, because at least the 
dependencies to the two or three Adobe artifacts that are not available via 
Maven.
Even if only manually deploying these artifacts isn't such a show-stopper as 
having to deploy the entire FDK, I think most users are used not having to 
do anything at all and this would prevent a lot of maven newbes from using 
flex in maven. At least this is the impression I am having while servicing 
the Flexmojos Mailinglist. Most users are consumers and not willing to eaven 
read a README file (Think you probably noticed that problem when releasing 
the first Apache Flex)

I can see the following scenarios (each step going down the maven road even 
further):
1. Using the Mavenizer to locally deploy FDKs.
2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those 
artifacts in a public repo.
3. Building Flex with Maven, eliminating the need to use the Mavenizer all 
together.

I agree that there might be some issues with the native packaging and mobile 
deployment. This is currently only handled by Velos Commercial Flexmojos 
Enterprize and these features are not part of the normal FM currently. So I 
agree that there might be some issues with the build needing more artifacts. 
But I think with the two or three artifacts discussed in this thread, we 
should be albe to target about 80% of the normal users use-cases. Being able 
to target 100% would be cooler, but 80% is better than 0%.

Chris


-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Gesendet: Sonntag, 25. November 2012 08:59
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?

>
Christopher Dutz gave me the impression that all Adobe would have to do is 
place a pom.xml alongside each playerglobal.swc.  Is there more to it?

I guess the goal behind that is to be able to get those artefact from a 
legal repo, we can not legaly provide them from inside the mavenized apache 
flex sdk, I guess what Chris want to do, is to make our sdk public via the 
apache repo and get those last artifacts from adobe, doing so, if only the 
the apache flex sdk is publicly available, that should not be a problem for 
companies to host internaly the new structure of the new sdk and the old 
structure of the others, they could use fm<6 and fm 6 on different projects.
The only thing is they shouldn't have to use the mavenizer to convert the 
SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.

- Fred.

-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

Exactly.

Currently noone is providing the FDKs publically, because at least the dependencies to the two or three Adobe artifacts that are not available via Maven.
Even if only manually deploying these artifacts isn't such a show-stopper as having to deploy the entire FDK, I think most users are used not having to do anything at all and this would prevent a lot of maven newbes from using flex in maven. At least this is the impression I am having while servicing the Flexmojos Mailinglist. Most users are consumers and not willing to eaven read a README file (Think you probably noticed that problem when releasing the first Apache Flex)

I can see the following scenarios (each step going down the maven road even further):
1. Using the Mavenizer to locally deploy FDKs.
2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those artifacts in a public repo.
3. Building Flex with Maven, eliminating the need to use the Mavenizer all together.

I agree that there might be some issues with the native packaging and mobile deployment. This is currently only handled by Velos Commercial Flexmojos Enterprize and these features are not part of the normal FM currently. So I agree that there might be some issues with the build needing more artifacts. But I think with the two or three artifacts discussed in this thread, we should be albe to target about 80% of the normal users use-cases. Being able to target 100% would be cooler, but 80% is better than 0%. 

Chris


-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoublefx@hotmail.com] 
Gesendet: Sonntag, 25. November 2012 08:59
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?

>
Christopher Dutz gave me the impression that all Adobe would have to do is place a pom.xml alongside each playerglobal.swc.  Is there more to it?

I guess the goal behind that is to be able to get those artefact from a legal repo, we can not legaly provide them from inside the mavenized apache flex sdk, I guess what Chris want to do, is to make our sdk public via the apache repo and get those last artifacts from adobe, doing so, if only the the apache flex sdk is publicly available, that should not be a problem for companies to host internaly the new structure of the new sdk and the old structure of the others, they could use fm<6 and fm 6 on different projects. 
The only thing is they shouldn't have to use the mavenizer to convert the SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.

- Fred.

-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even 
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is 
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?

I guess the goal behind that is to be able to get those artefact from a 
legal repo, we can not legaly provide them from inside the mavenized apache 
flex sdk, I guess what Chris want to do, is to make our sdk public via the 
apache repo and get those last artifacts from adobe, doing so, if only the 
the apache flex sdk is publicly available, that should not be a problem for 
companies to host internaly the new structure of the new sdk and the old 
structure of the others, they could use fm<6 and fm 6 on different projects. 
The only thing is they shouldn't have to use the mavenizer to convert the 
SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.

- Fred.

-----Message d'origine----- 
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even 
> if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
>
>
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is 
> THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
>
>

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
>
>
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
>

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

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/24/12 9:28 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> The mavenizer replace at the moment the lack of public repositories, even if
> it's good enough for individuals and small companies, it is not for big
> ones.
The main issue with Adobe making its stuff Maven friendly is legal.  There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos.  Why is this not ok for big companies?
> 
> 
> If Adobe and Apache decide to finaly host and deploy these frameworks in a
> maven repository, they will have to mavenized them and the mavenizer is THE
> TOOL for.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc.  Is there more to it?
> 
> 

>> So, with my limited understanding of Maven, the goal was to have Apache
>> Flex
> releases have a pom.xml and live in the Apache Maven repo, and have Adobe
> playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
> server
> 
> 
> Yes, you're right, it's just that for Air, the entire sdk is needed.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
> 

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer.  My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo.  Please correct me if
that is not true.  I'm still trying to learn all of this stuff.


For every AIR/Flex SDKs from a given directory structure, the mavenizer 
compiles, zip, renames, re-organizes the entries
- For the compiler jars and the framework swc, it renames the files, create 
a pom.xml and re-organize them in a final directory structure.
- For the themes, if a it's a swc, that's like above, if it's not, it 
compiles it and do like above.
- Creates the sources and the config zips and then like above
- Create the pom.xml aggregators for the air-framework, the air 
common-framework, flex common-framework and the flex-air common-framework
(and maybe I forgot something, it's late)


The mavenizer replace at the moment the lack of public repositories, even if 
it's good enough for individuals and small companies, it is not for big 
ones.


If Adobe and Apache decide to finaly host and deploy these frameworks in a 
maven repository, they will have to mavenized them and the mavenizer is THE 
TOOL for.


>Also, Apache Flex is trying to break any tie between the Apache Flex SDK 
>and
an AIR SDK.  Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.


You right, but like in current the SDK, there's a default FP/AIR that you 
can change with few efforts, it's the same with the mavenized one.


>So, with my limited understanding of Maven, the goal was to have Apache 
>Flex
releases have a pom.xml and live in the Apache Maven repo, and have Adobe
playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
server


Yes, you're right, it's just that for Air, the entire sdk is needed.


>and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.


If all the SDKs become mavenized and hosted on public repositories, the only 
use of the mavenizer gonna be to create those SDKs and push them to these 
public repositories and preferably done by the companies who own these SDKs.


>Thanks for being patient.  I'm still coming up to speed on this stuff.

Welcome :)


- Fred.

-----Message d'origine----- 
From: Alex Harui
Sent: Sunday, November 25, 2012 5:15 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?




On 11/24/12 5:16 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


>
> Switching SDK, is as easy as changing a property in only one pom.xml,
> nothing else to do as soon as the SDK you want to use is mavenized
> obviously, the player itself is not needed, we can specify the target
> version but there's no dependencies.
> During the SDK mavenization process (with the mavenizer), a relation 
> between
> Flex SDK and Air SDK is etablished, it's done by comparing the checksum of
> the airglobal.swc inside each Air SDKs and the ones inside each Flex SDKs.
I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer.  My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo.  Please correct me if
that is not true.  I'm still trying to learn all of this stuff.

Also, Apache Flex is trying to break any tie between the Apache Flex SDK and
an AIR SDK.  Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.

So, with my limited understanding of Maven, the goal was to have Apache Flex
releases have a pom.xml and live in the Apache Maven repo, and have Adobe
playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
server, and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.

Or will there still be a mavenizer that needs to be run?  If so, what will
it do?
>
>> but when building a .AIR file (and or an AIRI for signing) or a mobile
>> package,
> I'm pretty sure other parts of the AIR SDK are involved and that they 
> might
> change between AIR versions.
>
> AFAIK, airglobal.swc and ADT only are needed for packaging into AIR, AIRI,
> ANE, EXE, APK, IPA, ..., at the moment FlexMojos uses a class of the 
> adt.jar
> called AIRPackager and call the createAIR method instead of using the ADT
> class, therefore it can package only  into AIR (which is already something
> appreciated).
If you look in an AIR SDK, there are lots of files in there.  Sure you might
only need to call adt.jar, but if you delete every other file in there
besides airglobal.swc, will you really get a valid AIR, AIRI, APK and
especially IPA?  I mean, the AIR runtime has to get processed into the IPA
right?  And the updater UI swfs in other packages?

And, I would still worry that adt.jar has some dependency

If you are pretty sure no other files are needed, let's actually try it.
Try using your mavenizer on a stripped down AIR SDK with only airglobal.swc
and adt.jar and see if you can create an IPA via maven.  Or I will put up a
couple of versions of those two files on a server somewhere and those of you
who use Maven can try to see if they can switch between them.
>
> Not sure I anwsered at everything you want, only the things I understood 
> you
> want, ask again please for more precisions.

Thanks for being patient.  I'm still coming up to speed on this stuff.

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

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/24/12 5:16 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:


> 
> Switching SDK, is as easy as changing a property in only one pom.xml,
> nothing else to do as soon as the SDK you want to use is mavenized
> obviously, the player itself is not needed, we can specify the target
> version but there's no dependencies.
> During the SDK mavenization process (with the mavenizer), a relation between
> Flex SDK and Air SDK is etablished, it's done by comparing the checksum of
> the airglobal.swc inside each Air SDKs and the ones inside each Flex SDKs.
I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer.  My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo.  Please correct me if
that is not true.  I'm still trying to learn all of this stuff.

Also, Apache Flex is trying to break any tie between the Apache Flex SDK and
an AIR SDK.  Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.

So, with my limited understanding of Maven, the goal was to have Apache Flex
releases have a pom.xml and live in the Apache Maven repo, and have Adobe
playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download
server, and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.

Or will there still be a mavenizer that needs to be run?  If so, what will
it do?
> 
>> but when building a .AIR file (and or an AIRI for signing) or a mobile
>> package,
> I'm pretty sure other parts of the AIR SDK are involved and that they might
> change between AIR versions.
> 
> AFAIK, airglobal.swc and ADT only are needed for packaging into AIR, AIRI,
> ANE, EXE, APK, IPA, ..., at the moment FlexMojos uses a class of the adt.jar
> called AIRPackager and call the createAIR method instead of using the ADT
> class, therefore it can package only  into AIR (which is already something
> appreciated).
If you look in an AIR SDK, there are lots of files in there.  Sure you might
only need to call adt.jar, but if you delete every other file in there
besides airglobal.swc, will you really get a valid AIR, AIRI, APK and
especially IPA?  I mean, the AIR runtime has to get processed into the IPA
right?  And the updater UI swfs in other packages?

And, I would still worry that adt.jar has some dependency

If you are pretty sure no other files are needed, let's actually try it.
Try using your mavenizer on a stripped down AIR SDK with only airglobal.swc
and adt.jar and see if you can create an IPA via maven.  Or I will put up a
couple of versions of those two files on a server somewhere and those of you
who use Maven can try to see if they can switch between them.
> 
> Not sure I anwsered at everything you want, only the things I understood you
> want, ask again please for more precisions.

Thanks for being patient.  I'm still coming up to speed on this stuff.

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

Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

>I'm not a Maven user, so maybe I'm unclear what the main use cases are. 
>One
of the ones that I was told about was quickly updating to new versions of
Flex, and I assumed it might also mean updating to new versions of the
player or AIR SDK.

Switching SDK, is as easy as changing a property in only one pom.xml, 
nothing else to do as soon as the SDK you want to use is mavenized 
obviously, the player itself is not needed, we can specify the target 
version but there's no dependencies.
During the SDK mavenization process (with the mavenizer), a relation between 
Flex SDK and Air SDK is etablished, it's done by comparing the checksum of 
the airglobal.swc inside each Air SDKs and the ones inside each Flex SDKs.

>but when building a .AIR file (and or an AIRI for signing) or a mobile 
>package,
I'm pretty sure other parts of the AIR SDK are involved and that they might
change between AIR versions.

AFAIK, airglobal.swc and ADT only are needed for packaging into AIR, AIRI, 
ANE, EXE, APK, IPA, ..., at the moment FlexMojos uses a class of the adt.jar 
called AIRPackager and call the createAIR method instead of using the ADT 
class, therefore it can package only  into AIR (which is already something 
appreciated).

Not sure I anwsered at everything you want, only the things I understood you 
want, ask again please for more precisions.

- Fred.

-----Message d'origine----- 
From: Alex Harui
Sent: Saturday, November 24, 2012 11:55 PM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?

I'm not a Maven user, so maybe I'm unclear what the main use cases are.  One
of the ones that I was told about was quickly updating to new versions of
Flex, and I assumed it might also mean updating to new versions of the
player or AIR SDK.

I can see dropping in new versions of playerglobal.swc or airglobal.swc, but
when building a .AIR file (and or an AIRI for signing) or a mobile package,
I'm pretty sure other parts of the AIR SDK are involved and that they might
change between AIR versions.

Or can you install an AIR SDK once and change airglobal versions and it will
all work?

-Alex


On 11/24/12 4:05 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:

> Hi,
>
> @Alex, not sure actually about what you mean by "cover release packaging 
> of
> AIR apps" but with flexmojos I can compile and package into AIR which once
> installed run an .exe, all it needs is airglobal.swc and adt.jar.
>
> See
> https://svn.apache.org/repos/asf/incubator/flex/whiteboard/fthomas/developerTo
> olSuite/trunk/
>
> If I missed something, please let me know.
>
> - Fred.
>
> -----Message d'origine-----
> From: Alex Harui
> Sent: Friday, November 23, 2012 9:53 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: AW: AW: Who's a flex compiler-configuration pro on this list?
>
> OK, let's wait until next week and see if others agree that just having
> different versions of airglobal.swc available from Adobe would be
> sufficient.  It is all you may need to compile a simple swf, but to 
> produce
> final release packages, I think there are other pieces of the AIR SDK that
> you need.  Maybe the FlexMojos testsuite doesn't cover release packaging 
> of
> AIR apps?
>
>
> On 11/23/12 4:45 AM, "christofer.dutz@c-ware.de" 
> <ch...@c-ware.de>
> wrote:
>
>> Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc
>> and
>> in the Flexmojos Testsuite there are tests for the different Air features
>> and
>> I am not having any trouble with that.
>> The only thing is that I do have to provide the same third party libs the
>> Flex
>> SDK needs to have provided. So if you are talking about these libs, you
>> might
>> be correct.
>> But It would already be a great improvement to be able to build Flex
>> applications without manual intervention.
>> I have to admit that I have never ever done any Air yet nor any of the
>> Flex
>> guys around here that I have worked with.
>>
>> Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just
>> that
>> for those not using it this would be a great improvement.
>>
>> Chris
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Alex Harui [mailto:aharui@adobe.com]
>> Gesendet: Donnerstag, 22. November 2012 17:26
>> An: flex-dev@incubator.apache.org
>> Betreff: Re: AW: Who's a flex compiler-configuration pro on this list?
>>
>>
>>
>>
>> On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
>> <ch...@c-ware.de> wrote:
>>
>>> Buuuuuut ... thinking of it :-)
>>>
>>> Mabe it would indeed be better to start with Falcon as this is
>>> definitely the future of Flex and Flexmojos already lets you build
>>> using MXMLC ... And I always wanted to start digging into it, but
>>> never actually found a usecase for it.
>>>
>>> @Alex: Perhaps if Adobe were to publish the playerglobal and the
>>> airglobal (Don't need the runtime ... think mavenizing the Runtim is
>>> too much ... would simply use the runtimes from PATH).
>>> Without those TWO artifacts the final solution would always be
>>> half-baked (No matter what compiler) as no user could: "simply add the
>>> plugin and start coding flex" :-) So what do you think? You make the
>>> one thing happen, and I'll do the second?
>>> ;-)
>>>
>> I need convincing that this will work for captive runtime for mobile 
>> apps,
>> and
>> not sure how you are supposed to get the other executables that help make
>> up
>> the AIR package.
>>
>> But if you want to try prototyping it, feel free.  I wll try to find time
>> to
>> help next week, if you need help.  I want to make sure it will work 
>> before
>> we
>> go ask for approvals.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>

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

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

I'm not a Maven user, so maybe I'm unclear what the main use cases are.  One
of the ones that I was told about was quickly updating to new versions of
Flex, and I assumed it might also mean updating to new versions of the
player or AIR SDK.

I can see dropping in new versions of playerglobal.swc or airglobal.swc, but
when building a .AIR file (and or an AIRI for signing) or a mobile package,
I'm pretty sure other parts of the AIR SDK are involved and that they might
change between AIR versions.

Or can you install an AIR SDK once and change airglobal versions and it will
all work?

-Alex


On 11/24/12 4:05 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:

> Hi,
> 
> @Alex, not sure actually about what you mean by "cover release packaging of
> AIR apps" but with flexmojos I can compile and package into AIR which once
> installed run an .exe, all it needs is airglobal.swc and adt.jar.
> 
> See 
> https://svn.apache.org/repos/asf/incubator/flex/whiteboard/fthomas/developerTo
> olSuite/trunk/
> 
> If I missed something, please let me know.
> 
> - Fred.
> 
> -----Message d'origine-----
> From: Alex Harui
> Sent: Friday, November 23, 2012 9:53 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: AW: AW: Who's a flex compiler-configuration pro on this list?
> 
> OK, let's wait until next week and see if others agree that just having
> different versions of airglobal.swc available from Adobe would be
> sufficient.  It is all you may need to compile a simple swf, but to produce
> final release packages, I think there are other pieces of the AIR SDK that
> you need.  Maybe the FlexMojos testsuite doesn't cover release packaging of
> AIR apps?
> 
> 
> On 11/23/12 4:45 AM, "christofer.dutz@c-ware.de" <ch...@c-ware.de>
> wrote:
> 
>> Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc
>> and
>> in the Flexmojos Testsuite there are tests for the different Air features
>> and
>> I am not having any trouble with that.
>> The only thing is that I do have to provide the same third party libs the
>> Flex
>> SDK needs to have provided. So if you are talking about these libs, you
>> might
>> be correct.
>> But It would already be a great improvement to be able to build Flex
>> applications without manual intervention.
>> I have to admit that I have never ever done any Air yet nor any of the
>> Flex
>> guys around here that I have worked with.
>> 
>> Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just
>> that
>> for those not using it this would be a great improvement.
>> 
>> Chris
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Alex Harui [mailto:aharui@adobe.com]
>> Gesendet: Donnerstag, 22. November 2012 17:26
>> An: flex-dev@incubator.apache.org
>> Betreff: Re: AW: Who's a flex compiler-configuration pro on this list?
>> 
>> 
>> 
>> 
>> On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
>> <ch...@c-ware.de> wrote:
>> 
>>> Buuuuuut ... thinking of it :-)
>>> 
>>> Mabe it would indeed be better to start with Falcon as this is
>>> definitely the future of Flex and Flexmojos already lets you build
>>> using MXMLC ... And I always wanted to start digging into it, but
>>> never actually found a usecase for it.
>>> 
>>> @Alex: Perhaps if Adobe were to publish the playerglobal and the
>>> airglobal (Don't need the runtime ... think mavenizing the Runtim is
>>> too much ... would simply use the runtimes from PATH).
>>> Without those TWO artifacts the final solution would always be
>>> half-baked (No matter what compiler) as no user could: "simply add the
>>> plugin and start coding flex" :-) So what do you think? You make the
>>> one thing happen, and I'll do the second?
>>> ;-)
>>> 
>> I need convincing that this will work for captive runtime for mobile apps,
>> and
>> not sure how you are supposed to get the other executables that help make
>> up
>> the AIR package.
>> 
>> But if you want to try prototyping it, feel free.  I wll try to find time
>> to
>> help next week, if you need help.  I want to make sure it will work before
>> we
>> go ask for approvals.
>> 
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 

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

Re: Who's a flex compiler-configuration pro on this list?

[Frédéric THOMAS <we...@hotmail.com>]

Hi,

@Alex, not sure actually about what you mean by "cover release packaging of 
AIR apps" but with flexmojos I can compile and package into AIR which once 
installed run an .exe, all it needs is airglobal.swc and adt.jar.

See 
https://svn.apache.org/repos/asf/incubator/flex/whiteboard/fthomas/developerToolSuite/trunk/

If I missed something, please let me know.

- Fred.

-----Message d'origine----- 
From: Alex Harui
Sent: Friday, November 23, 2012 9:53 PM
To: flex-dev@incubator.apache.org
Subject: Re: AW: AW: Who's a flex compiler-configuration pro on this list?

OK, let's wait until next week and see if others agree that just having
different versions of airglobal.swc available from Adobe would be
sufficient.  It is all you may need to compile a simple swf, but to produce
final release packages, I think there are other pieces of the AIR SDK that
you need.  Maybe the FlexMojos testsuite doesn't cover release packaging of
AIR apps?


On 11/23/12 4:45 AM, "christofer.dutz@c-ware.de" <ch...@c-ware.de>
wrote:

> Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc 
> and
> in the Flexmojos Testsuite there are tests for the different Air features 
> and
> I am not having any trouble with that.
> The only thing is that I do have to provide the same third party libs the 
> Flex
> SDK needs to have provided. So if you are talking about these libs, you 
> might
> be correct.
> But It would already be a great improvement to be able to build Flex
> applications without manual intervention.
> I have to admit that I have never ever done any Air yet nor any of the 
> Flex
> guys around here that I have worked with.
>
> Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just 
> that
> for those not using it this would be a great improvement.
>
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: Alex Harui [mailto:aharui@adobe.com]
> Gesendet: Donnerstag, 22. November 2012 17:26
> An: flex-dev@incubator.apache.org
> Betreff: Re: AW: Who's a flex compiler-configuration pro on this list?
>
>
>
>
> On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
> <ch...@c-ware.de> wrote:
>
>> Buuuuuut ... thinking of it :-)
>>
>> Mabe it would indeed be better to start with Falcon as this is
>> definitely the future of Flex and Flexmojos already lets you build
>> using MXMLC ... And I always wanted to start digging into it, but
>> never actually found a usecase for it.
>>
>> @Alex: Perhaps if Adobe were to publish the playerglobal and the
>> airglobal (Don't need the runtime ... think mavenizing the Runtim is
>> too much ... would simply use the runtimes from PATH).
>> Without those TWO artifacts the final solution would always be
>> half-baked (No matter what compiler) as no user could: "simply add the
>> plugin and start coding flex" :-) So what do you think? You make the
>> one thing happen, and I'll do the second?
>> ;-)
>>
> I need convincing that this will work for captive runtime for mobile apps, 
> and
> not sure how you are supposed to get the other executables that help make 
> up
> the AIR package.
>
> But if you want to try prototyping it, feel free.  I wll try to find time 
> to
> help next week, if you need help.  I want to make sure it will work before 
> we
> go ask for approvals.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>

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

Re: AW: AW: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

OK, let's wait until next week and see if others agree that just having
different versions of airglobal.swc available from Adobe would be
sufficient.  It is all you may need to compile a simple swf, but to produce
final release packages, I think there are other pieces of the AIR SDK that
you need.  Maybe the FlexMojos testsuite doesn't cover release packaging of
AIR apps?


On 11/23/12 4:45 AM, "christofer.dutz@c-ware.de" <ch...@c-ware.de>
wrote:

> Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc and
> in the Flexmojos Testsuite there are tests for the different Air features and
> I am not having any trouble with that.
> The only thing is that I do have to provide the same third party libs the Flex
> SDK needs to have provided. So if you are talking about these libs, you might
> be correct. 
> But It would already be a great improvement to be able to build Flex
> applications without manual intervention.
> I have to admit that I have never ever done any Air yet nor any of the Flex
> guys around here that I have worked with.
> 
> Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just that
> for those not using it this would be a great improvement.
> 
> Chris
> 
> -----Ursprüngliche Nachricht-----
> Von: Alex Harui [mailto:aharui@adobe.com]
> Gesendet: Donnerstag, 22. November 2012 17:26
> An: flex-dev@incubator.apache.org
> Betreff: Re: AW: Who's a flex compiler-configuration pro on this list?
> 
> 
> 
> 
> On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
> <ch...@c-ware.de> wrote:
> 
>> Buuuuuut ... thinking of it :-)
>> 
>> Mabe it would indeed be better to start with Falcon as this is
>> definitely the future of Flex and Flexmojos already lets you build
>> using MXMLC ... And I always wanted to start digging into it, but
>> never actually found a usecase for it.
>> 
>> @Alex: Perhaps if Adobe were to publish the playerglobal and the
>> airglobal (Don't need the runtime ... think mavenizing the Runtim is
>> too much ... would simply use the runtimes from PATH).
>> Without those TWO artifacts the final solution would always be
>> half-baked (No matter what compiler) as no user could: "simply add the
>> plugin and start coding flex" :-) So what do you think? You make the
>> one thing happen, and I'll do the second?
>> ;-)
>> 
> I need convincing that this will work for captive runtime for mobile apps, and
> not sure how you are supposed to get the other executables that help make up
> the AIR package.
> 
> But if you want to try prototyping it, feel free.  I wll try to find time to
> help next week, if you need help.  I want to make sure it will work before we
> go ask for approvals.
> 
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
> 

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

AW: AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

Well my Mavenizer doesn't deploy any air stuff besides the airglobal.swc and in the Flexmojos Testsuite there are tests for the different Air features and I am not having any trouble with that.
The only thing is that I do have to provide the same third party libs the Flex SDK needs to have provided. So if you are talking about these libs, you might be correct. 
But It would already be a great improvement to be able to build Flex applications without manual intervention.
I have to admit that I have never ever done any Air yet nor any of the Flex guys around here that I have worked with.

Don't get me wrong. I'm not claiming that Nobody uses Air ... it's just that for those not using it this would be a great improvement.

Chris

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




On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> Buuuuuut ... thinking of it :-)
> 
> Mabe it would indeed be better to start with Falcon as this is 
> definitely the future of Flex and Flexmojos already lets you build 
> using MXMLC ... And I always wanted to start digging into it, but 
> never actually found a usecase for it.
> 
> @Alex: Perhaps if Adobe were to publish the playerglobal and the 
> airglobal (Don't need the runtime ... think mavenizing the Runtim is 
> too much ... would simply use the runtimes from PATH).
> Without those TWO artifacts the final solution would always be 
> half-baked (No matter what compiler) as no user could: "simply add the 
> plugin and start coding flex" :-) So what do you think? You make the 
> one thing happen, and I'll do the second?
> ;-)
> 
I need convincing that this will work for captive runtime for mobile apps, and not sure how you are supposed to get the other executables that help make up the AIR package.

But if you want to try prototyping it, feel free.  I wll try to find time to help next week, if you need help.  I want to make sure it will work before we go ask for approvals.

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

Re: AW: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/21/12 11:59 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> Buuuuuut ... thinking of it :-)
> 
> Mabe it would indeed be better to start with Falcon as this is definitely the
> future of Flex and Flexmojos already lets you build using MXMLC ... And I
> always wanted to start digging into it, but never actually found a usecase for
> it.
> 
> @Alex: Perhaps if Adobe were to publish the playerglobal and the airglobal
> (Don't need the runtime ... think mavenizing the Runtim is too much ... would
> simply use the runtimes from PATH).
> Without those TWO artifacts the final solution would always be half-baked (No
> matter what compiler) as no user could: "simply add the plugin and start
> coding flex" :-) 
> So what do you think? You make the one thing happen, and I'll do the second?
> ;-)
> 
I need convincing that this will work for captive runtime for mobile apps,
and not sure how you are supposed to get the other executables that help
make up the AIR package.

But if you want to try prototyping it, feel free.  I wll try to find time to
help next week, if you need help.  I want to make sure it will work before
we go ask for approvals.

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

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

Buuuuuut ... thinking of it :-) 

Mabe it would indeed be better to start with Falcon as this is definitely the future of Flex and Flexmojos already lets you build using MXMLC ... And I always wanted to start digging into it, but never actually found a usecase for it.

@Alex: Perhaps if Adobe were to publish the playerglobal and the airglobal (Don't need the runtime ... think mavenizing the Runtim is too much ... would simply use the runtimes from PATH).
Without those TWO artifacts the final solution would always be half-baked (No matter what compiler) as no user could: "simply add the plugin and start coding flex" :-) 
So what do you think? You make the one thing happen, and I'll do the second? ;-)

Chris


-----Ursprüngliche Nachricht-----
Von: christofer.dutz@c-ware.de [mailto:christofer.dutz@c-ware.de] 
Gesendet: Mittwoch, 21. November 2012 21:25
An: flex-dev@incubator.apache.org
Betreff: AW: Who's a flex compiler-configuration pro on this list?

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" <cf...@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" <go...@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

Re: AW: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

On 11/21/12 12:24 PM, "christofer.dutz@c-ware.de"
<ch...@c-ware.de> wrote:

> 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
Well, we have a bunches of patches, fixed bugs and some new locales that I
think we should release soon, and I don't see us getting Falcon ready in
that timeframe.

However, I will be spending as much time as I can on Falcon otherwise, and
Gordon knows the Falcon code better than MXMLC.  And I think you'll find the
code easier to work with.

So if you want to get the basics of your work done for this next release (it
might not happen until late December or January) via MXMLC that's fine, but
I would definitely recommend saving optimization work for Falcon.

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

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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" <cf...@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" <go...@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

Re: Who's a flex compiler-configuration pro on this list?

[Carol Frampton <cf...@adobe.com>]

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

>I'm could be wrong but I'm sure this API was orginally done so that

that should have been "I could be wrong but I'm pretty sure this API was
originally 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" <go...@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
>>> >
>>> >
>>>
>

Re: Who's a flex compiler-configuration pro on this list?

[Alex Harui <ah...@adobe.com>]

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" <cf...@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" <go...@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

Re: Who's a flex compiler-configuration pro on this list?

[Carol Frampton <cf...@adobe.com>]

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" <go...@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
>> >
>> >
>>

RE: Who's a flex compiler-configuration pro on this list?

[Gordon Smith <go...@adobe.com>]

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
> >
> >
>

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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
> >
> >
>

Re: Who's a flex compiler-configuration pro on this list?

[Maxime Cowez <ma...@gmail.com>]

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/gradlefx/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
> >
> >
>

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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/gradlefx/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
>
>

AW: Who's a flex compiler-configuration pro on this list?

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

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/gradlefx/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
>
>

Re: Who's a flex compiler-configuration pro on this list?

[Maxime Cowez <ma...@gmail.com>]

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/gradlefx/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
>
>