incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 19:34:21 GMT

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

View raw message