Sounds good to me. - Gordon
-----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Friday, July 13, 2012 4:07 PM To: flex-dev@incubator.apache.org Subject: Re: Falcon location in Apache repository Probably the opposite falcon/trunk, similar to flex/trunk. We'll figure out an integration strategy later. TLF will probably end up in a similar folder. BlazeDS as well. We can move it around later. On 7/13/12 4:03 PM, "Gordon Smith" <gosm...@adobe.com> wrote: > I think it will be confusing to have projects for the old compiler and > project for the new compiler mingled together in the trunk/modules directory. > Currently there are two Eclipse projects, one for the Falcon compiler > itself and one for its JUnit tests. And there will be a third and > possibly fourth assuming that FalconJS eventually gets donated. > > Can it have its own trunk/falcon or trunk/compiler or trunk/java directory? > > - Gordon > > -----Original Message----- > From: Gordon Smith [mailto:gosm...@adobe.com] > Sent: Friday, July 13, 2012 1:53 PM > To: flex-dev@incubator.apache.org > Cc: Peter Farland > Subject: Falcon update > > Greetings, Apache Flex community! > > Some of you already know me from my previous work on the Flex SDK > (beginning with Flex 1.0), and my occasional comments on this list > regarding the architecture of the Falcon compiler that Adobe has been > developing for the last two years. > > I've been watching as you put the finishing touches on the 4.8.0 > parity release. Congratulations on being close! > > I've also been working hard for the last several months to get Falcon > ready to donate to Apache. The ActionScript functionality is complete > except for integrating last-minute bugfixes that we continue to make > in our mainline. I'd estimate the MXML functionality as being 85% > complete. As you know, after Adobe's refocused its priorities last > fall, we froze the MXML work to concentrate on completing ActionScript > to shipping quality, but the MXML support hasn't regressed. As an > example, Falcon can compile the SDK's non-trivial CheckinApp test, except for > the Repeater tag. > > The main things left before donation are revising the build script to > meet Apache standards and satisfying Adobe's Legal department. I can't > make any predictions on a donation date, but things seem to be moving along > nicely. > We'll donate various test suites later; they require more legal > scrutiny than the code does. > > After donation, I'll be working on Apache Falcon one day a week as an > Adobe employee. My goal will be to get Falcon to the point where it > can compile the Flex SWCs and then compile Mustella tests that link > against those SWCs, run, and pass. I'll also be happy to work on > high-priority bugs that the community identifies, such as when you try > Falcon out on your own apps and find compilation problems. But I will > helping to reach parity with the old compiler, not with evolving > Falcon in entirely new directions. Of course, you are free to do that! > (I'd suggest doing it on a branch until we reach parity.) > > The areas of Falcon that need the most work are > > * states (mostly implemented) > * databinding (partly implemented) > * reporting MXML semantic problems (partly implemented) > * Repeater (not implemented) > * ASDoc (not implemented) > > I'll be concentrating primarily on the first two in order to reach the > goal I mentioned. I hope that some of you will be interested in > working on Falcon so that it reaches its potential. > > I ask for your understanding as I come up to speed on Apache > procedures and standards. > > Gordon Smith, Adobe compiler team > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
