On Aug 15, 2012 9:07 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > On 8/15/12 12:51 AM, "Om" <bigosma...@gmail.com> wrote: > > > On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <aha...@adobe.com> wrote: > > > >> > >> > >> > >> On 8/14/12 10:51 PM, "Om" <bigosma...@gmail.com> wrote: > >> > >>> I dint see a strong reason for Falcon to be a top level project anywhere > >> in > >>> this thread. > >>> > >> I think we eventually want to break the compiler's ties to a specific > >> version of the SDK. That gives it a better chance to be incorporated into > >> IDEs and used for other things like code models, and to be used as a front > >> end to FalconJS. > >> > >> > > MXML is a feature of the Flex SDK. How can we ship Falcon without the Flex > > SDK? Who would be using it? > It is the other way around. We should have the flexibility to deliver > Falcon separately from the SDK. The commercial tool vendors shouldn't have > to re-integrate Falcon every time we cut a new release of the SDK. That is > why they cannot leverage MXMLC in the IDEs other than strictly as the SWF > compiler. > > > I agree that it is the way to go in the long run. But, from Gordon's description, it does not sound like Falcon its anywhere close to achieving this. In the short term, making it a top level project creates a barrier that would prevent people contributing to it. Which in turn would delay the eventual goal of making a separate release of Falcon.
> > > > > > In the long term, it probably makes sense to move it a top level project, > > but in the short term having it outside of the current flex sdk folder > > structure will make it extremely difficult to work with. No one has > > answered Gordon's question: > > > > 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."? > >> > > > > This sounds like a nightmare. Scenarios like these are the reasons why > > having feature branches makes sense. Isnt this what we all discussed in > > great detail in the "branching thread"? > Features of a single deliverable like the SDK. But I think Falcon should be > thought of as a separate sub-project. TLF as well. Both Falcon and TLF can > be involved in SWFs without any other SDK code in it. Is there any reason why we can't do the same while having Falcon inside the modules directory? Once we achieve this goal, we can move it out to a separate project. > > > > Yet another issue I raised that has not been addressed: > > > > 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. > >> > I'm not understanding. The proposed folder structure has "sub-project" > names at the top. I don't see folders called 'asc' or 'compiler' > > Gordon mentioned that Falcon replaces the ' legacy compiler' which are the projects asc and compiler. This means that once Falcon proves itself, we would make the switch and get rid of the legacy ones. Retaining the name 'Falcon' at that point would only cause confusion. In the end, here is what I am proposing: Lets keep Falcon inside /flex/trunk/modules/falcon. It would make working with it much easier. Work on making Falcon sdk-independent can also happen here. Once that goal is achieved, we can move it to a too level project-by which time it should just be a directory copy. If we still want to make Falcon a top level project, I would like to see how the the the typical developer set up would look like. Just saying consider it a top level project without figuring out the dev setup is not very helpful in making such a decision. Gordon asked the same question and has not been discussed in this thread. > > Thanks, > > Om
