The thread was continued as "Rearrangement of ... Flex". Did you read that one too? In any case, I think the discussion can continue and perhaps you will persuade people. But my initial post explained why I don't think it belongs in 'modules', and no one else has wanted it there.
- Gordon Sent from my iPad On Aug 14, 2012, at 10:52 PM, "Om" <bigosma...@gmail.com> wrote: > On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <gosm...@adobe.com> wrote: > >> A large majority of people replying to this thread favor SDK, Falcon, TLF, >> BlazeDS, etc. being quasi-independent sub projects within the overall Flex >> project, so that's what Carol is planning for. >> >> > I think we should discuss this further at the end of which a vote should be > taken. I don't think we are done discussing this yet to make this change. > > I dint see a strong reason for Falcon to be a top level project anywhere in > this thread. > > Thanks, > Om > > >> Sent from my iPad >> >> On Aug 14, 2012, at 10:23 PM, "Om" <bigosma...@gmail.com> wrote: >> >>> On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <gosm...@adobe.com> wrote: >>> >>>>> Falcon is a new version of the Actionscript compiler. >>>> >>>> Falcon is a reimplementation of mxmlc and compc. The AS support is very >>>> good. (It will ship as FB 4.7.) The MXML support is incomplete but >> Falcon >>>> can compile the framework test file Checkinapp.mxml. >>>> >>>>> Does it support mxml as well? Or would that be a separate top level >>>> project? >>>> >>>> See above. >>>> >>>>> What do we call the compiler that is currently inside trunk? >>>> >>>> I call it "the legacy compiler". >>>> >>>>> If falcon gets a new top level project, shouldnt the current compiler >>>> get its own top level project? >>>> >>>> I don't have an opinion on that. I hope the old compiler dies as soon as >>>> possible. >>>> >>>>> Does Falcon work with exisiting flex sdk? >>>> >>>> It 's intended to eventually, but it's not yet ready to compile and run >>>> all SDK SWCs and tests yet. >>>> >>>>> If I create new components inside incubator/flex/SDK/trunk/, should I >>>> worry about who Falcon will work with it? How would I set up my >> project in >>>> that case? >>>> >>>> Unless you want to contribute to Falcon, you shouldn't worry about it. >> At >>>> some point, if it becomes a suitable replacement for the legacy >> compiler, >>>> we will switch over and everything should just work the same. >>>> >>>>> Should I have copies of my new components in both >>>> incubator/flex/SDK/trunk/ and incubator/flex/Falcon/trunk/ to run both >>>> Mustella tests and Falcon's tests? >>>> >>>> No; incubator/flex/Falcon/trunk will be only for Falcon's Java code. No >>>> framework components will live there. >>>> >>>>> Does Falcon share any code with Falcon JS? >>>> >>>> Yes, it shares a front end (lexer/parser/symbol table). FalconJS and >>>> Falcon have different back ends (code generators). FalconJS is not ready >>>> for donation. >>>> >>>>> If yes, how might we want to change the repo structure if/when FalconJS >>>> is contributed to Apache Flex? >>>> >>>> We can figure that out when FalconJS is ready, but I think making it a >>>> sibling of Falcon would be best. It could share Falcon's front end just >> by >>>> putting Falcon's JAR on its classpath. >>>> >>>> - Gordon >>>> >>>> >>> Thanks Gordon! >>> >>> From what I read, it looks like Falcon is a new feature that will be >> added >>> to Apache Flex. I believe it should be under >> /flex/trunk/modules/falcon. >>> And since it might be highly unstable, we should probably create a >> 'falcon' >>> branch to do this in. Especially since you want to replace >>> /flex/trunk/modules/asc and /flex/trunk/modules/compile with the falcon >>> compiler. >>> >>> I think this structure follows what we have been discussing in the >>> branching strategy threads. >>> >>> Elsewhere, you said: >>> >>> If Flex has independent subprojects like SDK, Falcon, TLF, etc., how >> would >>>> we tie them all together to do testing? With environment variables that >> say >>>> "use this branch of the SDK, this branch of Falcon, this branch of TLF, >>>> etc."? >>>> >>> >>> Keeping it under /flex/trunk/modules/falcon would solve this problem too, >>> right? >>> >>> Eventually we should throwaway the /flex/trunk/modules/asc/ (legacy >>> compiler) and rename falcon to asc as well. >>> >>> As I see it, Falcon is a codename for a new version of the compiler. We >>> are mixing functional names like "asc" and "compiler" with codenames like >>> "falcon". What happens when we want to build a new version of >> actionscript >>> compiler after falcon? We dont want to have that existing alongside with >>> another codename as well. >>> >>> Thanks, >>> Om >>
