> I am sorry if I sound like I dont support modularity. But that is not > what I am saying here. By Gordon's (who is probably the only person on > this list who knows the Falcon codebase) own admission, Falcon is tied > closely to the Flex framework because of the semantics of MXML. Falcon is only tied to the Flex framework because the current code took the approach of trying to generate the same sdk-version-dependent generated code that MXMLC does today. MXMLC could also be changed to generate something less version-dependent.
> > But, until that level of separation is achieved, how can I as a developer > make sure that Falcon works with the current sdk that I want to ship in the > next release? If you switch out MXMLC for Falcon and all mustella tests pass, you are good to go. > > I keep seeing the word 'eventually'. All I am saying is, in that eventual > case, lets make Falcon a top level project. There is nothing preventing > anyone from modularizing and separating the concerns of Falcon while still > under modules/falcon. But the other way round, making Falcon a top level > project prevents me from working with it in the short term. I don't follow your logic. Your installer is not in the sdk tree but you are certainly able to work on it. > > Alex: >> Yes, there is a bit more overhead, but is should be worth it. >> > > How do we know if it is worth it if we don't know what exactly the overhead > is? Falcon compiles out to a set of jars just like modules does today. There is little overhead. > No one has proposed a workflow to working with Falcon as a top-level > project yet. That's because the way it was worked on in Adobe will be different than the way it is worked on in Apache. As with all prior donations, the goal was to get it donated. We should put it in a folder structure that denotes a desired configuration (separate from the SDK) and then we'll adjust build scripts and documentation to make a good workflow. I have no idea how folks are going to want to test their changes to Falcon. For me, I had some simple test files and simply called the MXMLC script equivalents instead. Others are going to want to use FB. We'll get that figured out after donation. > > Whereas, I am proposing a workflow which is to keep Falcon under modules > and create a separate branch where this would be the main feature. Anyone > who wants to work with Falcon can simply switch to that feature branch. > Convince me why this is not a better idea. The only reason against it so > far is: "it will be confusing". Why is this confusing? > I don't believe I said it was confusing. I think if the long term goal is separation, we should organize it like that from the beginning so we don't accidentally lean on something we shouldn't. IMO, you should not need a whole branch of the SDK just to run Falcon's AS-only capabilities. Yes, technically we could work in either folder structure, but I think you are the only one currently arguing to put it in modules so I think the tree Carol proposed will happen regardless of if you are convinced or not. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
