You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Gordon Smith <go...@adobe.com> on 2012/08/14 20:05:30 UTC
Falcon location
I'd like to start a discussion of where Falcon will live in the Apache repository.
The initial donation will be an Eclipse project and Ant scripts for building Falcon itself. Later we will donate another Eclipse project and Ant scripts for testing Falcon
Although it is Java code, I don't think it should go into trunk/modules with the older compiler. It would be confusing to have a bunch of subdirectories in trunk/modules, some of which are for the old compiler and some of which are for the new compiler. So I propose that the two Falcon projects live inside trunk/falcon.
Like the old compiler, Falcon is tied closely to the Flex framework because of the semantics of MXML. Therefore, I think Falcon belongs initially "inside" Flex, like the old compiler was inside Flex. Eventually, it would be interesting to try break many of these dependencies and let Falcon become its own project independent of the framework, but I see that as longer-term evolution.
- Gordon
Re: Falcon location
Posted by Roland Zwaga <ro...@stackandheap.com>.
> On 8/14/12 11:16 AM, "Roland Zwaga" <ro...@stackandheap.com> wrote:
>
>>> Gordon
>>>
>>> What you think under trunck/falcon ?
>>>
>>
>> trunk/falcon sounds reasonable to me as well.
>>
>> Roland
>
> Putting falcon under trunk means it will likely need to be blocked from the
> next release as I don't think falcon will be ready with MXML support in a
> couple of months.
Aha, so you're implying that it should first be imported in a branch then?
I hadn't thought about the release schedule actually, makes sense now...
Re: Falcon location
Posted by João Fernandes <jo...@gmail.com>.
Jeff, that's why I think we should have for each distinct project a trunk /
branches /tags folder (thanks Carol for pointing out). So If we get Falcon
donated, it doesn't have to fit within the SDK and we don't need to worry
the fact it's incomplete and don't get a "instable" trunk.
João Fernandes
Re: Falcon location
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 8/14/2012 2:16 PM, Roland Zwaga wrote:
>> Gordon
>>
>> What you think under trunck/falcon ?
>>
> trunk/falcon sounds reasonable to me as well.
>
> Roland
As I understood it; the trunk is, essentially, working code for the
existing Flex SDK. Since Falcon is not yet integrated as part of the
Flex SDK; I'm not sure how much sense doing the initial commit into the
trunk makes.
My impulse is to put it in some place that is currently separate from
other sources.
Perhaps in a directory (Falcon) that is at the same level as trunk.
Or perhaps in a whiteboard, or branch, that is specific to Falcon.
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/14/12 11:16 AM, "Roland Zwaga" <ro...@stackandheap.com> wrote:
>> Gordon
>>
>> What you think under trunck/falcon ?
>>
>
> trunk/falcon sounds reasonable to me as well.
>
> Roland
Putting falcon under trunk means it will likely need to be blocked from the
next release as I don't think falcon will be ready with MXML support in a
couple of months.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Roland Zwaga <ro...@stackandheap.com>.
> Gordon
>
> What you think under trunck/falcon ?
>
trunk/falcon sounds reasonable to me as well.
Roland
Re: Falcon location
Posted by Igor Costa <ig...@gmail.com>.
Gordon
What you think under trunck/falcon ?
Regards
----------------------------
Igor Costa
www.igorcosta.com
www.igorcosta.org
On Tue, Aug 14, 2012 at 3:05 PM, Gordon Smith <go...@adobe.com> wrote:
> I'd like to start a discussion of where Falcon will live in the Apache
> repository.
>
> The initial donation will be an Eclipse project and Ant scripts for
> building Falcon itself. Later we will donate another Eclipse project and
> Ant scripts for testing Falcon
>
> Although it is Java code, I don't think it should go into trunk/modules
> with the older compiler. It would be confusing to have a bunch of
> subdirectories in trunk/modules, some of which are for the old compiler and
> some of which are for the new compiler. So I propose that the two Falcon
> projects live inside trunk/falcon.
>
> Like the old compiler, Falcon is tied closely to the Flex framework
> because of the semantics of MXML. Therefore, I think Falcon belongs
> initially "inside" Flex, like the old compiler was inside Flex. Eventually,
> it would be interesting to try break many of these dependencies and let
> Falcon become its own project independent of the framework, but I see that
> as longer-term evolution.
>
> - Gordon
>
>
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tue, Aug 14, 2012 at 11:17 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/14/12 11:05 AM, "Gordon Smith" <go...@adobe.com> wrote:
>
> > I'd like to start a discussion of where Falcon will live in the Apache
> > repository.
> >
> > The initial donation will be an Eclipse project and Ant scripts for
> building
> > Falcon itself. Later we will donate another Eclipse project and Ant
> scripts
> > for testing Falcon
> >
> > Although it is Java code, I don't think it should go into trunk/modules
> with
> > the older compiler. It would be confusing to have a bunch of
> subdirectories in
> > trunk/modules, some of which are for the old compiler and some of which
> are
> > for the new compiler. So I propose that the two Falcon projects live
> inside
> > trunk/falcon.
> >
> > Like the old compiler, Falcon is tied closely to the Flex framework
> because of
> > the semantics of MXML. Therefore, I think Falcon belongs initially
> "inside"
> > Flex, like the old compiler was inside Flex. Eventually, it would be
> > interesting to try break many of these dependencies and let Falcon
> become its
> > own project independent of the framework, but I see that as longer-term
> > evolution.
> >
> > - Gordon
> >
> FWIW, keep in mind we also expect TLF to get VP signature this week as well
> and BlazeDS is in progress. IMO, All three are standalone entities and
> should have top-level project status. I don't know how hard it is to move
> the current trunk into an directory called sdk, but that would be my first
> choice as in, when you go here:
> https://svn.apache.org/repos/asf/incubator/flex/
Well, if we were using Git, we could just move it, commit and be done.
(Sorry, I had to! hehe, I'm just teasing here)
>
>
> You currently see:
> branches
> external
> import2
> site
> tags
> trunk
> utilities
> whiteboard
>
> And I would like us to have:
> blazeds
> external
> falcon
> import2
> site
> tlf
> sdk
> branches <-- these 3 are moved down from the top level
> tags
> trunk
> utilities
> whiteboard
>
> I'm not sure now is the right time to be moving trunk so I'd be willing to
> live with some inconsistency right now and just have
> blazeds
> branches
> external
> falcon
> import2
> site
> tags
> tlf
> trunk <-- this is the current top-level trunk
> utilities
> whiteboard
>
> Thoughts?
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I would opt for the second choice, leave trunk along and add /falcon etc.
-omar
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, August 14, 2012, Gordon Smith wrote:
>
>
> I like your lowercase names better. (sdk rather than SDK, etc.)
>
> - Gordon
>
>
>
+1 to lowercase names. :)
-omar
RE: rearrangement of
https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Gordon Smith <go...@adobe.com>.
You're showing the contents of incubator/flex, right?
I like your lowercase names better. (sdk rather than SDK, etc.)
- Gordon
-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com]
Sent: Tuesday, August 14, 2012 1:00 PM
To: flex-dev@incubator.apache.org
Subject: rearrangement of https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
I'm planning to reorganize svn on Thursday AM (EDT) as follows:
site
external
falcon
branches
tags
trunk
whiteboard
blazeds
branches
tags
trunk
whiteboard
sdk
branches
tags
trunk
whiteboard
tlf
branches
tags
trunk
whiteboard
utilities
branches
tags
trunk
whiteboard
and delete import2 left over from one of the imports from Adobe
Carol
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Jeff Conrad <je...@gmail.com>.
Awesome!
When this happens, can it be set up so there are multiple read-only git
mirrors / repositories at that point? i.e. flex-sdk, flex-blazeds,
flex-falcon, flex-tlf, flex-utilities, etc.?
Jeff
On Tue, Aug 14, 2012 at 4:21 PM, Greg Reddin <gr...@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 3:00 PM, Carol Frampton <cf...@adobe.com>
> wrote:
> > I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>
> Looks good.
>
> Greg
>
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Greg Reddin <gr...@gmail.com>.
On Tue, Aug 14, 2012 at 3:00 PM, Carol Frampton <cf...@adobe.com> wrote:
> I'm planning to reorganize svn on Thursday AM (EDT) as follows:
Looks good.
Greg
Re: Falcon location
Posted by Om <bi...@gmail.com>.
Thanks, that helps! I believe you when you say that the overhead is going
to be low. That is what I care about.
Regards,
Om
On Wed, Aug 15, 2012 at 12:34 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > 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
>
>
RE: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
Falcon is tied to the SDK, the text components in the SDK are tied to TLF, the networking classes in the SDK are clients of BlazeDS, etc. Flex is an ecosystem that all works together and you can't just mix-and-match any version of one part with any version of another part.
But I now agree with Alex and others that the various subparts need to be able to evolve independently rather than all being in a single trunk.
So that means we need some way of tying them all together in order to test, or in order to produce a "here's everything you need" release, and I don't think we're clear on how that might work. But I'm sure we can figure something out.
- Gordon
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Wednesday, August 15, 2012 12:19 PM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location
On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez
<om...@gmail.com>wrote:
> >
> > IMO, you are arguing against the principle of modularity and/or
> separation
> > of concerns. Yes, there is a bit more overhead, but is should be
> > worth
> it.
> > You voted for a much more complex branching strategy supposedly in
> > favor
> of
> > modularity. I'm surprised you are pushing back on it here.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
> This ^^^.
>
> -omar
>
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. I agree that this is not a good thing. I agree that this should be changed.
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?
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.
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? No one has proposed a workflow to working with Falcon as a top-level project yet.
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?
Thanks,
Om
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
> 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
Re: Falcon location
Posted by Om <bi...@gmail.com>.
On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez
<om...@gmail.com>wrote:
> >
> > IMO, you are arguing against the principle of modularity and/or
> separation
> > of concerns. Yes, there is a bit more overhead, but is should be worth
> it.
> > You voted for a much more complex branching strategy supposedly in favor
> of
> > modularity. I'm surprised you are pushing back on it here.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
> This ^^^.
>
> -omar
>
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. I agree
that this is not a good thing. I agree that this should be changed.
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?
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.
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? No one has proposed a workflow to working with Falcon as a top-level
project yet.
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?
Thanks,
Om
RE: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
> This ^^^.
???
- Gordon
-----Original Message-----
From: Omar Gonzalez [mailto:omarg.developer@gmail.com]
Sent: Wednesday, August 15, 2012 11:45 AM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location
>
> IMO, you are arguing against the principle of modularity and/or
> separation of concerns. Yes, there is a bit more overhead, but is should be worth it.
> You voted for a much more complex branching strategy supposedly in
> favor of modularity. I'm surprised you are pushing back on it here.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
This ^^^.
-omar
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
>
> IMO, you are arguing against the principle of modularity and/or separation
> of concerns. Yes, there is a bit more overhead, but is should be worth it.
> You voted for a much more complex branching strategy supposedly in favor of
> modularity. I'm surprised you are pushing back on it here.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
This ^^^.
-omar
Re: Falcon location
Posted by Carol Frampton <cf...@adobe.com>.
While I have no problem naming the directory flex/falcon I do understand
Om's concern that it is a code name that people may not know.
flex/newcompiler isn't very pretty.
Carol
On 8/15/12 2 :18PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 8/15/12 10:43 AM, "Om" <bi...@gmail.com> wrote:
>
>> On Aug 15, 2012 9:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>
>
>>>
>> 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.
>For me (and I think for everyone else reading this thread so far)
>separation
>now seems better as it makes it clear you should not add more SDK
>dependencies to the compiler.
>
>>> 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.
>See above.
>>
>>
>> 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.
>Well, it is only Wednesday, and so far, nobody has joined your side so on
>Thursday, I think we're going to make the tree as Carol most recently
>proposed it.
>>
>> 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.
>>
>I'm sure we can figure it out. Flex is already comprised of several other
>Apache TLPs like Batik and Velocity. It should be even easier to handle
>one
>that is actually somewhere else in our own repo.
>
>IMO, you are arguing against the principle of modularity and/or separation
>of concerns. Yes, there is a bit more overhead, but is should be worth
>it.
>You voted for a much more complex branching strategy supposedly in favor
>of
>modularity. I'm surprised you are pushing back on it here.
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 10:43 AM, "Om" <bi...@gmail.com> wrote:
> On Aug 15, 2012 9:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>
>>
> 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.
For me (and I think for everyone else reading this thread so far) separation
now seems better as it makes it clear you should not add more SDK
dependencies to the compiler.
>> 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.
See above.
>
>
> 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.
Well, it is only Wednesday, and so far, nobody has joined your side so on
Thursday, I think we're going to make the tree as Carol most recently
proposed it.
>
> 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.
>
I'm sure we can figure it out. Flex is already comprised of several other
Apache TLPs like Batik and Velocity. It should be even easier to handle one
that is actually somewhere else in our own repo.
IMO, you are arguing against the principle of modularity and/or separation
of concerns. Yes, there is a bit more overhead, but is should be worth it.
You voted for a much more complex branching strategy supposedly in favor of
modularity. I'm surprised you are pushing back on it here.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Om <bi...@gmail.com>.
On Aug 15, 2012 9:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>
> On 8/15/12 12:51 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >>
> >> On 8/14/12 10:51 PM, "Om" <bi...@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
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 12:51 AM, "Om" <bi...@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 8/14/12 10:51 PM, "Om" <bi...@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.
>
>
>
> 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.
>
> 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'
>
> Thanks,
> Om
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Om <bi...@gmail.com>.
On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/14/12 10:51 PM, "Om" <bi...@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?
This is Gordon's original comment and I agree with it:
Like the old compiler, Falcon is tied closely to the Flex framework because
> of the semantics of MXML. Therefore, I think Falcon belongs initially
> "inside" Flex, like the old compiler was inside Flex. Eventually, it would
> be interesting to try break many of these dependencies and let Falcon
> become its own project independent of the framework, but I see that as
> longer-term evolution.
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"?
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.
>
Thanks,
Om
Re: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
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" <bi...@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <go...@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" <bi...@gmail.com> wrote:
>>
>>> On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <go...@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
>>
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, August 14, 2012, Om wrote:
> On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <gosmith@adobe.com<javascript:;>>
> 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
>
>
We don't have to vote on every little thing I form a consensus. At this
point you're the only one not in agreement, if I've followed the thread
thoroughly.
-omar
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/14/12 10:51 PM, "Om" <bi...@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.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Om <bi...@gmail.com>.
On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <go...@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" <bi...@gmail.com> wrote:
>
> > On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <go...@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
>
Re: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
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.
Sent from my iPad
On Aug 14, 2012, at 10:23 PM, "Om" <bi...@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <go...@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
Re: Falcon location
Posted by Om <bi...@gmail.com>.
On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <go...@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
RE: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
> 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
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Tuesday, August 14, 2012 12:59 PM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location
Gordon,
Sorry for jumping late into this thread, but I am not sure what exactly Falcon is at this point. I was hoping that you would post some wiki pages about what exactly Falcon is. There is very little public information about Falcon (that I could google)
>From what I understand (please correct me if I am wrong), Falcon is a new version of the Actionscript compiler.
Does it support mxml as well? Or would that be a separate top level project?
What do we call the compiler that is currently inside trunk?
If falcon gets a new top level project, shouldnt the current compiler get its own top level project?
Does Falcon work with exisiting flex sdk? 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?
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?
(Thinking ahead) Does Falcon share any code with Falcon JS? If yes, how might we want to change the repo structure if/when FalconJS is contributed to Apache Flex?
Sorry, if some of these questions sound stupid. But we will be able to make a better judgement of where it should go if we knew some more details.
Thanks,
Om
On Tue, Aug 14, 2012 at 12:43 PM, Gordon Smith <go...@adobe.com> wrote:
> It seems like the momentum is for
>
> incubator/flex
> incubator/flex/SDK
> incubator/flex/SDK/trunk
> incubator/flex/SDK/branches
> incubator/flex/SDK/tags
> incubator/flex/SDK/whiteboard
> incubator/flex/Falcon
> incubator/flex/Falcon/trunk
> incubator/flex/Falcon/branches
> incubator/flex/Falcon/tags
> incubator/flex/Falcon/whiteboard
> incubator/flex/TLF
> incubator/flex/TLF/trunk
> incubator/flex/TLF/branches
> incubator/flex/TLF/tags
> incubator/flex/TLF/whiteboard
>
> Should the SDK directory be called Framework instead? To me, the SDK
> is something that would be produced at the incubator/flex level from
> all the subprojects.
>
> - Gordon
>
> -----Original Message-----
> From: Jonathan Campos [mailto:jonbcampos@gmail.com]
> Sent: Tuesday, August 14, 2012 11:43 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Falcon location
>
> On Tue, Aug 14, 2012 at 1:32 PM, Carol Frampton <cf...@adobe.com>
> wrote:
>
> > +1 except remove projects directory and put each project at
> > +top-level and
> > add tags subdirectory under each project
> >
>
> Agreed with Carol.
>
> --
> Jonathan Campos
>
Re: Falcon location
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> To me that sounds like a kludge with little benefit and presumably worse performance than either compiler by itself.
Fair enough.
> I take it that you are unhappy with the decision to compile MXML directly to ABC
No as such but I don't understand the reasoning behind it.
> What is the main problem that you use -keep to solve?
So we can use Falcon now and hopefully gain some benefit from it. Not having worked on Falcon or seen the code I:
a) have no idea if my suggestion is possible
b) would give any improvements
Thanks,
Justin
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, August 14, 2012, Gordon Smith wrote:
> Even without FC (which I would forget about), don't you find it easier to
> skin in MXML because of its support for states? I am not concerned about
> making Falcon able to compile MXML skins. They are less complicated than
> MXML apps.
>
> - Gordon
>
> Sent from my iPad
Agreed. I was just making the point that we should forget about FC.
-omar
Re: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
Even without FC (which I would forget about), don't you find it easier to skin in MXML because of its support for states? I am not concerned about making Falcon able to compile MXML skins. They are less complicated than MXML apps.
- Gordon
Sent from my iPad
On Aug 14, 2012, at 10:40 PM, "Omar Gonzalez" <om...@gmail.com> wrote:
> On Tuesday, August 14, 2012, Alex Harui wrote:
>
>>
>>
>>
>> On 8/14/12 9:51 PM, "Justin Mclean" <justin@classsoftware.com<javascript:;>>
>> wrote:
>>
>>> Hi,
>>>
>>>> I think Justin's looking for a stop gap solution for compiling MXML with
>>>> Falcon.
>>> 100% correct.
>>>
>> Interesting idea. However, I think AS compilation from scratch (as opposed
>> to incremental compilation used in the IDE) is only 2 or 3 times faster
>> than
>> MXML, and the time spent writing out the AS and reading it in again won't
>> save you anything (which, IIRC, is sort of one reason they made the
>> decision
>> to compile MXML straight to ABC)
>>
>> Also, the current generated code from MXMLC can't just be compiled and
>> turned into a SWF. Some massaging has to take place, also slowing you
>> down.
>>
>> Now, could you use Falcon now to build the Flex SDK? Almost. IIRC, there
>> was one MXML file in the mx.swc and more in the Spark Skins. Replacing
>> MXML
>> skins with AS skins would make them faster, but then they would be less
>> useful in tools like FC.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
> Being one of the strongest proponents of FC (I am in the promo video on the
> product page :P ) Should we even consider that tool for anything? It's EOL,
> why would we not do something like make AS skins instead of MXML to
> preserve FC support?
>
> -omar
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/14/12 10:39 PM, "Omar Gonzalez" <om...@gmail.com> wrote:
> On Tuesday, August 14, 2012, Alex Harui wrote:
> Being one of the strongest proponents of FC (I am in the promo video on the
> product page :P ) Should we even consider that tool for anything? It's EOL,
> why would we not do something like make AS skins instead of MXML to
> preserve FC support?
>
> -omar
MXML is easier to create tools for, and for people to learn and code.
That's why Mustella tests are in MXML, to support eventual tools and make it
easier for QA. If we're very lucky, some FC-like thing will be created by
the Apache Flex community and/or by one of the tooling vendors.
The basic premise of FC is still compelling, but the actual implementation
had its challenges.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, August 14, 2012, Alex Harui wrote:
>
>
>
> On 8/14/12 9:51 PM, "Justin Mclean" <justin@classsoftware.com<javascript:;>>
> wrote:
>
> > Hi,
> >
> >> I think Justin's looking for a stop gap solution for compiling MXML with
> >> Falcon.
> > 100% correct.
> >
> Interesting idea. However, I think AS compilation from scratch (as opposed
> to incremental compilation used in the IDE) is only 2 or 3 times faster
> than
> MXML, and the time spent writing out the AS and reading it in again won't
> save you anything (which, IIRC, is sort of one reason they made the
> decision
> to compile MXML straight to ABC)
>
> Also, the current generated code from MXMLC can't just be compiled and
> turned into a SWF. Some massaging has to take place, also slowing you
> down.
>
> Now, could you use Falcon now to build the Flex SDK? Almost. IIRC, there
> was one MXML file in the mx.swc and more in the Spark Skins. Replacing
> MXML
> skins with AS skins would make them faster, but then they would be less
> useful in tools like FC.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Being one of the strongest proponents of FC (I am in the promo video on the
product page :P ) Should we even consider that tool for anything? It's EOL,
why would we not do something like make AS skins instead of MXML to
preserve FC support?
-omar
Re: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
As I've explained a few times, Falcon already has substantial support for MXML. For example, it can compile Checkinapp, one of the SDK's test apps, except for the Repeater tag in it. I encourage people to help me finish Falcon so that it can replace the legacy compiler ASAP. The first thing you can do to help after donation is to try Falcon on your own MXML apps, find what doesn't work properly, reduce the problem to a simple test case, and file a bug. I'll be happy to prioritize the bugs that get the most votes. But I'll be happier if people start learning how Falcon works and pitch in to help me fix the remaining weak spots. Falcon has a lot of Javadoc which I think you'll find very helpful.
- Gordon
Sent from my iPad
On Aug 14, 2012, at 9:52 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I think Justin's looking for a stop gap solution for compiling MXML with
>> Falcon.
> 100% correct.
>
> Thanks,
> Justin
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/14/12 9:51 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I think Justin's looking for a stop gap solution for compiling MXML with
>> Falcon.
> 100% correct.
>
Interesting idea. However, I think AS compilation from scratch (as opposed
to incremental compilation used in the IDE) is only 2 or 3 times faster than
MXML, and the time spent writing out the AS and reading it in again won't
save you anything (which, IIRC, is sort of one reason they made the decision
to compile MXML straight to ABC)
Also, the current generated code from MXMLC can't just be compiled and
turned into a SWF. Some massaging has to take place, also slowing you down.
Now, could you use Falcon now to build the Flex SDK? Almost. IIRC, there
was one MXML file in the mx.swc and more in the Spark Skins. Replacing MXML
skins with AS skins would make them faster, but then they would be less
useful in tools like FC.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Falcon location
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think Justin's looking for a stop gap solution for compiling MXML with
> Falcon.
100% correct.
Thanks,
Justin
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, August 14, 2012, Gordon Smith wrote:
> Hi, Justin.
>
> To me that sounds like a kludge with little benefit and presumably worse
> performance than either compiler by itself. I take it that you are unhappy
> with the decision to compile MXML directly to ABC, for maximum performance,
> if it means losing -keep? If so, you could work on a alternate compilation
> path for MXML in Falcon that involved either real or fake (i.e., not
> actually compiled) AS. What is the main problem that you use -keep to
> solve? Perhaps Falcon's option that displays MXML syntax trees could be
> another solution for you.
>
> - Gordon
>
> Sent from my iPad
>
> On Aug 14, 2012, at 6:26 PM, "Justin Mclean" <justin@classsoftware.com<javascript:;>>
> wrote:
>
> > Hi,
> >
> >> Falcon right now is an ActionScript compiler with limited MXML support,
> so
> >> right now you can't simply change the old compiler by the new one.
> >
> > Probably some reason to why we cant do this but couldn't we use the
> current compiler to turn MXML into AS (-keep of top of head) and then use
> Falcon to compile that AS?
> >
> > Justin
>
I think Justin's looking for a stop gap solution for compiling MXML with
Falcon. At least that's what I read from it.
-omar
Re: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
Hi, Justin.
To me that sounds like a kludge with little benefit and presumably worse performance than either compiler by itself. I take it that you are unhappy with the decision to compile MXML directly to ABC, for maximum performance, if it means losing -keep? If so, you could work on a alternate compilation path for MXML in Falcon that involved either real or fake (i.e., not actually compiled) AS. What is the main problem that you use -keep to solve? Perhaps Falcon's option that displays MXML syntax trees could be another solution for you.
- Gordon
Sent from my iPad
On Aug 14, 2012, at 6:26 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> Falcon right now is an ActionScript compiler with limited MXML support, so
>> right now you can't simply change the old compiler by the new one.
>
> Probably some reason to why we cant do this but couldn't we use the current compiler to turn MXML into AS (-keep of top of head) and then use Falcon to compile that AS?
>
> Justin
Re: Falcon location
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Falcon right now is an ActionScript compiler with limited MXML support, so
> right now you can't simply change the old compiler by the new one.
Probably some reason to why we cant do this but couldn't we use the current compiler to turn MXML into AS (-keep of top of head) and then use Falcon to compile that AS?
Justin
Re: Falcon location
Posted by João Fernandes <jo...@gmail.com>.
Om,
Falcon right now is an ActionScript compiler with limited MXML support, so
right now you can't simply change the old compiler by the new one.
João Fernandes
Re: Falcon location
Posted by Om <bi...@gmail.com>.
Gordon,
Sorry for jumping late into this thread, but I am not sure what exactly
Falcon is at this point. I was hoping that you would post some wiki pages
about what exactly Falcon is. There is very little public information
about Falcon (that I could google)
>From what I understand (please correct me if I am wrong), Falcon is a new
version of the Actionscript compiler.
Does it support mxml as well? Or would that be a separate top level
project?
What do we call the compiler that is currently inside trunk?
If falcon gets a new top level project, shouldnt the current compiler get
its own top level project?
Does Falcon work with exisiting flex sdk? 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?
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?
(Thinking ahead) Does Falcon share any code with Falcon JS? If yes, how
might we want to change the repo structure if/when FalconJS is contributed
to Apache Flex?
Sorry, if some of these questions sound stupid. But we will be able to
make a better judgement of where it should go if we knew some more details.
Thanks,
Om
On Tue, Aug 14, 2012 at 12:43 PM, Gordon Smith <go...@adobe.com> wrote:
> It seems like the momentum is for
>
> incubator/flex
> incubator/flex/SDK
> incubator/flex/SDK/trunk
> incubator/flex/SDK/branches
> incubator/flex/SDK/tags
> incubator/flex/SDK/whiteboard
> incubator/flex/Falcon
> incubator/flex/Falcon/trunk
> incubator/flex/Falcon/branches
> incubator/flex/Falcon/tags
> incubator/flex/Falcon/whiteboard
> incubator/flex/TLF
> incubator/flex/TLF/trunk
> incubator/flex/TLF/branches
> incubator/flex/TLF/tags
> incubator/flex/TLF/whiteboard
>
> Should the SDK directory be called Framework instead? To me, the SDK is
> something that would be produced at the incubator/flex level from all the
> subprojects.
>
> - Gordon
>
> -----Original Message-----
> From: Jonathan Campos [mailto:jonbcampos@gmail.com]
> Sent: Tuesday, August 14, 2012 11:43 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Falcon location
>
> On Tue, Aug 14, 2012 at 1:32 PM, Carol Frampton <cf...@adobe.com>
> wrote:
>
> > +1 except remove projects directory and put each project at top-level and
> > add tags subdirectory under each project
> >
>
> Agreed with Carol.
>
> --
> Jonathan Campos
>
Re: Falcon location
Posted by Carol Frampton <cf...@adobe.com>.
On 8/14/12 3 :43PM, "Gordon Smith" <go...@adobe.com> wrote:
>It seems like the momentum is for
>
>incubator/flex
>incubator/flex/SDK
>incubator/flex/SDK/trunk
>incubator/flex/SDK/branches
>incubator/flex/SDK/tags
>incubator/flex/SDK/whiteboard
>incubator/flex/Falcon
>incubator/flex/Falcon/trunk
>incubator/flex/Falcon/branches
>incubator/flex/Falcon/tags
>incubator/flex/Falcon/whiteboard
>incubator/flex/TLF
>incubator/flex/TLF/trunk
>incubator/flex/TLF/branches
>incubator/flex/TLF/tags
>incubator/flex/TLF/whiteboard
>
>Should the SDK directory be called Framework instead? To me, the SDK is
>something that would be produced at the incubator/flex level from all the
>subprojects.
I'd say no because there are already too many framework(s) directories
under trunk. We'd have framework/frameworks/projects/framework.
Carol
RE: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
It seems like the momentum is for
incubator/flex
incubator/flex/SDK
incubator/flex/SDK/trunk
incubator/flex/SDK/branches
incubator/flex/SDK/tags
incubator/flex/SDK/whiteboard
incubator/flex/Falcon
incubator/flex/Falcon/trunk
incubator/flex/Falcon/branches
incubator/flex/Falcon/tags
incubator/flex/Falcon/whiteboard
incubator/flex/TLF
incubator/flex/TLF/trunk
incubator/flex/TLF/branches
incubator/flex/TLF/tags
incubator/flex/TLF/whiteboard
Should the SDK directory be called Framework instead? To me, the SDK is something that would be produced at the incubator/flex level from all the subprojects.
- Gordon
-----Original Message-----
From: Jonathan Campos [mailto:jonbcampos@gmail.com]
Sent: Tuesday, August 14, 2012 11:43 AM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location
On Tue, Aug 14, 2012 at 1:32 PM, Carol Frampton <cf...@adobe.com> wrote:
> +1 except remove projects directory and put each project at top-level and
> add tags subdirectory under each project
>
Agreed with Carol.
--
Jonathan Campos
Re: Falcon location
Posted by Jonathan Campos <jo...@gmail.com>.
On Tue, Aug 14, 2012 at 1:32 PM, Carol Frampton <cf...@adobe.com> wrote:
> +1 except remove projects directory and put each project at top-level and
> add tags subdirectory under each project
>
Agreed with Carol.
--
Jonathan Campos
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Omar Gonzalez <om...@gmail.com>.
On Tue, Aug 14, 2012 at 1:00 PM, Carol Frampton <cf...@adobe.com> wrote:
> I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>
> site
> external
> falcon
> branches
> tags
> trunk
> whiteboard
> blazeds
> branches
> tags
> trunk
> whiteboard
> sdk
> branches
> tags
> trunk
> whiteboard
> tlf
> branches
> tags
> trunk
> whiteboard
> utilities
> branches
> tags
> trunk
> whiteboard
>
>
>
> and delete import2 left over from one of the imports from Adobe
>
> Carol
>
>
This structure looks good to me and I think is ideal in SVN.
-omar
Re: Falcon location
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 8/14/2012 2:35 PM, Omar Gonzalez wrote:
> On Tue, Aug 14, 2012 at 11:32 AM, Carol Frampton <cf...@adobe.com> wrote:
>
>> +1 except remove projects directory and put each project at top-level and
>> add tags subdirectory under each project
>>
>>
> +1, I like Carol's suggestion with João's structure.
>
>
I could get behind that. My impulse is to keep the projects
directory; but add the tags subdirectory on each project.
Re: Falcon location
Posted by Omar Gonzalez <om...@gmail.com>.
On Tue, Aug 14, 2012 at 11:32 AM, Carol Frampton <cf...@adobe.com> wrote:
> +1 except remove projects directory and put each project at top-level and
> add tags subdirectory under each project
>
>
+1, I like Carol's suggestion with João's structure.
-omar
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 15, 2012 at 3:35 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>...you may want to still have a top level whiteboard directory with sub
> directories (falcon, blazeds, sdk etc) rather than one under each project ...
I agree, no need for any rigid structure in whiteboard IMO - it's just
a playground.
-Bertrand
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I'm planning to reorganize svn on Thursday AM (EDT) as follows:
Structure looks good me. Although you may want to still have a top level whiteboard directory with sub directories (falcon, blazeds, sdk etc) rather than one under each project so you one need to look in one spot for whiteboards. I don't have a strong option re this, just a suggestion and either way is fine.
Thanks,
Justin
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Om <bi...@gmail.com>.
Carol,
We are still discussing the Falcon location in the other thread. Can you
please hold off on making this change until we finish?
Thanks,
Om
On Aug 15, 2012 8:14 AM, "Carol Frampton" <cf...@adobe.com> wrote:
> I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>
>
> Updated to move remove whiteboard from each sub-project
>
> site
> external
> falcon
> branches
> tags
> trunk
> blazeds
> branches
> tags
> trunk
> sdk
> branches
> tags
> trunk
>
> tlf
> branches
> tags
> trunk
>
> utilities
> branches
> tags
> trunk
> whiteboard
>
>
> Carol
>
> On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
>
> >I'm planning to reorganize svn on Thursday AM (EDT) as follows:
> >
> >site
> >external
> >falcon
> > branches
> > tags
> > trunk
> > whiteboard
> >blazeds
> > branches
> > tags
> > trunk
> > whiteboard
> >sdk
> > branches
> > tags
> > trunk
> > whiteboard
> >tlf
> > branches
> > tags
> > trunk
> > whiteboard
> >utilities
> > branches
> > tags
> > trunk
> > whiteboard
> >
> >
> >
> >and delete import2 left over from one of the imports from Adobe
> >
> >Carol
> >
>
>
Re: rearrangement of
https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Alex Harui <ah...@adobe.com>.
On 8/18/12 2:22 AM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> What has to be done, that the github repository get synced with the new
> flex structure? Or is this task already in progress?
Hopefully the folks setting up Git for Apache Flex will also deal with this.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Cyrill Zadra <cy...@gmail.com>.
What has to be done, that the github repository get synced with the new
flex structure? Or is this task already in progress?
On Thu, Aug 16, 2012 at 9:24 PM, Nicholas Kwiatkowski <ni...@spoon.as>wrote:
> I'll update the site. I'll change the "view the source" page to outline
> the different projects we are hosting too. I'm just finishing up a
> conference call at the moment, but will take care of it shortly.
>
> -Nick
>
> On Thu, Aug 16, 2012 at 2:34 PM, Carol Frampton <cf...@adobe.com>
> wrote:
>
> > Nick,
> >
> > As a result of the svn reorg, the svn URL on this page needs to be
> updated
> > [1]. There may be other places as well. Any links to the README out
> > there also have to be updated.
> >
> > If I edit the page under site what else do I have to do to make it live.
> > Unfortunately I've only half paid attention to the site stuff so I think
> > it has to be "pushed" or something to have changes show up.
> >
> > Carol
> >
> > [1] http://incubator.apache.org/flex/source.html
> >
> >
> > On 8/16/12 10 :08AM, "Carol Frampton" <cf...@adobe.com> wrote:
> >
> > >I've started this rearrangement. You should now be doing development
> work
> > >out of
> > >
> https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/developwhich
> > >is a copy of trunk at rev 1373837.
> > >
> > >Depending on how you are managing your code you may want to do a "svn
> > >switch" or just re-checkout your code.
> > >
> > >Carol
> > >
> > >On 8/15/12 11 :13AM, "Carol Frampton" <cf...@adobe.com> wrote:
> > >
> > >>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
> > >>
> > >>
> > >>Updated to move remove whiteboard from each sub-project
> > >>
> > >>site
> > >>external
> > >>falcon
> > >> branches
> > >> tags
> > >> trunk
> > >>blazeds
> > >> branches
> > >> tags
> > >> trunk
> > >>sdk
> > >> branches
> > >> tags
> > >> trunk
> > >>
> > >>tlf
> > >> branches
> > >> tags
> > >> trunk
> > >>
> > >>utilities
> > >> branches
> > >> tags
> > >> trunk
> > >>whiteboard
> > >>
> > >>
> > >>Carol
> > >>
> > >>On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
> > >>
> > >>>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
> > >>>
> > >>>site
> > >>>external
> > >>>falcon
> > >>> branches
> > >>> tags
> > >>> trunk
> > >>> whiteboard
> > >>>blazeds
> > >>> branches
> > >>> tags
> > >>> trunk
> > >>> whiteboard
> > >>>sdk
> > >>> branches
> > >>> tags
> > >>> trunk
> > >>> whiteboard
> > >>>tlf
> > >>> branches
> > >>> tags
> > >>> trunk
> > >>> whiteboard
> > >>>utilities
> > >>> branches
> > >>> tags
> > >>> trunk
> > >>> whiteboard
> > >>>
> > >>>
> > >>>
> > >>>and delete import2 left over from one of the imports from Adobe
> > >>>
> > >>>Carol
> > >>>
> > >>
> > >
> >
> >
>
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
I'll update the site. I'll change the "view the source" page to outline
the different projects we are hosting too. I'm just finishing up a
conference call at the moment, but will take care of it shortly.
-Nick
On Thu, Aug 16, 2012 at 2:34 PM, Carol Frampton <cf...@adobe.com> wrote:
> Nick,
>
> As a result of the svn reorg, the svn URL on this page needs to be updated
> [1]. There may be other places as well. Any links to the README out
> there also have to be updated.
>
> If I edit the page under site what else do I have to do to make it live.
> Unfortunately I've only half paid attention to the site stuff so I think
> it has to be "pushed" or something to have changes show up.
>
> Carol
>
> [1] http://incubator.apache.org/flex/source.html
>
>
> On 8/16/12 10 :08AM, "Carol Frampton" <cf...@adobe.com> wrote:
>
> >I've started this rearrangement. You should now be doing development work
> >out of
> >https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/developwhich
> >is a copy of trunk at rev 1373837.
> >
> >Depending on how you are managing your code you may want to do a "svn
> >switch" or just re-checkout your code.
> >
> >Carol
> >
> >On 8/15/12 11 :13AM, "Carol Frampton" <cf...@adobe.com> wrote:
> >
> >>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
> >>
> >>
> >>Updated to move remove whiteboard from each sub-project
> >>
> >>site
> >>external
> >>falcon
> >> branches
> >> tags
> >> trunk
> >>blazeds
> >> branches
> >> tags
> >> trunk
> >>sdk
> >> branches
> >> tags
> >> trunk
> >>
> >>tlf
> >> branches
> >> tags
> >> trunk
> >>
> >>utilities
> >> branches
> >> tags
> >> trunk
> >>whiteboard
> >>
> >>
> >>Carol
> >>
> >>On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
> >>
> >>>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
> >>>
> >>>site
> >>>external
> >>>falcon
> >>> branches
> >>> tags
> >>> trunk
> >>> whiteboard
> >>>blazeds
> >>> branches
> >>> tags
> >>> trunk
> >>> whiteboard
> >>>sdk
> >>> branches
> >>> tags
> >>> trunk
> >>> whiteboard
> >>>tlf
> >>> branches
> >>> tags
> >>> trunk
> >>> whiteboard
> >>>utilities
> >>> branches
> >>> tags
> >>> trunk
> >>> whiteboard
> >>>
> >>>
> >>>
> >>>and delete import2 left over from one of the imports from Adobe
> >>>
> >>>Carol
> >>>
> >>
> >
>
>
Re: rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Om <bi...@gmail.com>.
On Thu, Aug 16, 2012 at 11:34 AM, Carol Frampton <cf...@adobe.com> wrote:
> Nick,
>
> As a result of the svn reorg, the svn URL on this page needs to be updated
> [1]. There may be other places as well. Any links to the README out
> there also have to be updated.
>
> If I edit the page under site what else do I have to do to make it live.
> Unfortunately I've only half paid attention to the site stuff so I think
> it has to be "pushed" or something to have changes show up.
>
>
1. Go to https://cms.apache.org/
2. Sign in
3. Search for 'Flex'
4. Click on 'Publish flex site' link
5. Click Submit button.
> Carol
>
> [1] http://incubator.apache.org/flex/source.html
>
>
Re: rearrangement of
https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Carol Frampton <cf...@adobe.com>.
Nick,
As a result of the svn reorg, the svn URL on this page needs to be updated
[1]. There may be other places as well. Any links to the README out
there also have to be updated.
If I edit the page under site what else do I have to do to make it live.
Unfortunately I've only half paid attention to the site stuff so I think
it has to be "pushed" or something to have changes show up.
Carol
[1] http://incubator.apache.org/flex/source.html
On 8/16/12 10 :08AM, "Carol Frampton" <cf...@adobe.com> wrote:
>I've started this rearrangement. You should now be doing development work
>out of
>https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/develop which
>is a copy of trunk at rev 1373837.
>
>Depending on how you are managing your code you may want to do a "svn
>switch" or just re-checkout your code.
>
>Carol
>
>On 8/15/12 11 :13AM, "Carol Frampton" <cf...@adobe.com> wrote:
>
>>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>>
>>
>>Updated to move remove whiteboard from each sub-project
>>
>>site
>>external
>>falcon
>> branches
>> tags
>> trunk
>>blazeds
>> branches
>> tags
>> trunk
>>sdk
>> branches
>> tags
>> trunk
>>
>>tlf
>> branches
>> tags
>> trunk
>>
>>utilities
>> branches
>> tags
>> trunk
>>whiteboard
>>
>>
>>Carol
>>
>>On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
>>
>>>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>>>
>>>site
>>>external
>>>falcon
>>> branches
>>> tags
>>> trunk
>>> whiteboard
>>>blazeds
>>> branches
>>> tags
>>> trunk
>>> whiteboard
>>>sdk
>>> branches
>>> tags
>>> trunk
>>> whiteboard
>>>tlf
>>> branches
>>> tags
>>> trunk
>>> whiteboard
>>>utilities
>>> branches
>>> tags
>>> trunk
>>> whiteboard
>>>
>>>
>>>
>>>and delete import2 left over from one of the imports from Adobe
>>>
>>>Carol
>>>
>>
>
Re: rearrangement of
https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Carol Frampton <cf...@adobe.com>.
I've started this rearrangement. You should now be doing development work
out of
https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/develop which
is a copy of trunk at rev 1373837.
Depending on how you are managing your code you may want to do a "svn
switch" or just re-checkout your code.
Carol
On 8/15/12 11 :13AM, "Carol Frampton" <cf...@adobe.com> wrote:
>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>
>
>Updated to move remove whiteboard from each sub-project
>
>site
>external
>falcon
> branches
> tags
> trunk
>blazeds
> branches
> tags
> trunk
>sdk
> branches
> tags
> trunk
>
>tlf
> branches
> tags
> trunk
>
>utilities
> branches
> tags
> trunk
>whiteboard
>
>
>Carol
>
>On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
>
>>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>>
>>site
>>external
>>falcon
>> branches
>> tags
>> trunk
>> whiteboard
>>blazeds
>> branches
>> tags
>> trunk
>> whiteboard
>>sdk
>> branches
>> tags
>> trunk
>> whiteboard
>>tlf
>> branches
>> tags
>> trunk
>> whiteboard
>>utilities
>> branches
>> tags
>> trunk
>> whiteboard
>>
>>
>>
>>and delete import2 left over from one of the imports from Adobe
>>
>>Carol
>>
>
Re: rearrangement of
https://svn.apache.org/repos/asf/incubator/flex (was Re: Falcon location)
Posted by Carol Frampton <cf...@adobe.com>.
I'm planning to reorganize svn on Thursday AM (EDT) as follows:
Updated to move remove whiteboard from each sub-project
site
external
falcon
branches
tags
trunk
blazeds
branches
tags
trunk
sdk
branches
tags
trunk
tlf
branches
tags
trunk
utilities
branches
tags
trunk
whiteboard
Carol
On 8/14/12 4 :00PM, "Carol Frampton" <cf...@adobe.com> wrote:
>I'm planning to reorganize svn on Thursday AM (EDT) as follows:
>
>site
>external
>falcon
> branches
> tags
> trunk
> whiteboard
>blazeds
> branches
> tags
> trunk
> whiteboard
>sdk
> branches
> tags
> trunk
> whiteboard
>tlf
> branches
> tags
> trunk
> whiteboard
>utilities
> branches
> tags
> trunk
> whiteboard
>
>
>
>and delete import2 left over from one of the imports from Adobe
>
>Carol
>
rearrangement of https://svn.apache.org/repos/asf/incubator/flex
(was Re: Falcon location)
Posted by Carol Frampton <cf...@adobe.com>.
I'm planning to reorganize svn on Thursday AM (EDT) as follows:
site
external
falcon
branches
tags
trunk
whiteboard
blazeds
branches
tags
trunk
whiteboard
sdk
branches
tags
trunk
whiteboard
tlf
branches
tags
trunk
whiteboard
utilities
branches
tags
trunk
whiteboard
and delete import2 left over from one of the imports from Adobe
Carol
Re: Falcon location
Posted by Carol Frampton <cf...@adobe.com>.
+1 except remove projects directory and put each project at top-level and
add tags subdirectory under each project
On 8/14/12 2 :26PM, "João Fernandes" <jo...@gmail.com>
wrote:
>why not
>site
>external
>projects
>>>> SDK
> >>> branches
> >>> trunk
> >>> whiteboard
>>>> Falcon
> >>> branches
> >>> trunk
> >>> whiteboard
>>>> BlazeDS
> >>> branches
> >>> trunk
> >>> whiteboard
>>>> Utilities
> >>> branches
> >>> trunk
> >>> whiteboard
>>>> TLF
> >>> branches
> >>> trunk
> >>> whiteboard
>>>>blazeds
> >>> branches
> >>> trunk
> >>> whiteboard
>...
>
>So each project can have different releases. Right now there are probably
>a
>few dependencies but probably we'll reach a point where some of those
>projects can envolve at a different pace.
>
>Something I would also like, if possible, is to create eventually an
>"extensions" project for small libs that could be donated an be part of
>the
>SDK but as optional lib.
>
>--
>
>João Fernandes
Re: Falcon location
Posted by João Fernandes <jo...@gmail.com>.
why not
site
external
projects
>>> SDK
>>> branches
>>> trunk
>>> whiteboard
>>> Falcon
>>> branches
>>> trunk
>>> whiteboard
>>> BlazeDS
>>> branches
>>> trunk
>>> whiteboard
>>> Utilities
>>> branches
>>> trunk
>>> whiteboard
>>> TLF
>>> branches
>>> trunk
>>> whiteboard
>>>blazeds
>>> branches
>>> trunk
>>> whiteboard
...
So each project can have different releases. Right now there are probably a
few dependencies but probably we'll reach a point where some of those
projects can envolve at a different pace.
Something I would also like, if possible, is to create eventually an
"extensions" project for small libs that could be donated an be part of the
SDK but as optional lib.
--
João Fernandes
Re: Falcon location
Posted by Greg Reddin <gr...@gmail.com>.
On Tue, Aug 14, 2012 at 1:17 PM, Alex Harui <ah...@adobe.com> wrote:
> And I would like us to have:
> blazeds
> external
> falcon
> import2
> site
> tlf
> sdk
> branches <-- these 3 are moved down from the top level
> tags
> trunk
> utilities
> whiteboard
>
> I'm not sure now is the right time to be moving trunk so I'd be willing to
> live with some inconsistency right now and just have
> blazeds
> branches
> external
> falcon
> import2
> site
> tags
> tlf
> trunk <-- this is the current top-level trunk
> utilities
> whiteboard
I'd be fine with either of those approaches.
Re: Falcon location
Posted by João Fernandes <jo...@gmail.com>.
On 14 August 2012 19:34, Gordon Smith <go...@adobe.com> wrote:
> 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."?
>
> - Gordon
I think it should be better doing something like that instead of having
dependent projects otherwise we'll never be able to have "independent"
projects with their own pace of development.
--
João Fernandes
RE: Falcon location
Posted by Gordon Smith <go...@adobe.com>.
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."?
- Gordon
-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com]
Sent: Tuesday, August 14, 2012 11:28 AM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location
On 8/14/12 2 :17PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 8/14/12 11:05 AM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> I'd like to start a discussion of where Falcon will live in the
>> Apache repository.
>>
>> The initial donation will be an Eclipse project and Ant scripts for
>>building Falcon itself. Later we will donate another Eclipse project
>>and Ant scripts for testing Falcon
>>
>> Although it is Java code, I don't think it should go into
>>trunk/modules with the older compiler. It would be confusing to have
>>a bunch of subdirectories in trunk/modules, some of which are for the
>>old compiler and some of which are for the new compiler. So I propose
>>that the two Falcon projects live inside trunk/falcon.
>>
>> Like the old compiler, Falcon is tied closely to the Flex framework
>>because of the semantics of MXML. Therefore, I think Falcon belongs
>>initially "inside"
>> Flex, like the old compiler was inside Flex. Eventually, it would be
>>interesting to try break many of these dependencies and let Falcon
>>become its own project independent of the framework, but I see that
>>as longer-term evolution.
>>
>> - Gordon
>>
>FWIW, keep in mind we also expect TLF to get VP signature this week as
>well and BlazeDS is in progress. IMO, All three are standalone
>entities and should have top-level project status. I don't know how
>hard it is to move the current trunk into an directory called sdk, but
>that would be my first choice as in, when you go here:
>https://svn.apache.org/repos/asf/incubator/flex/
>
>You currently see:
> branches
> external
> import2
> site
> tags
> trunk
> utilities
> whiteboard
>
>And I would like us to have:
> blazeds
> external
> falcon
> import2
> site
> tlf
> sdk
> branches <-- these 3 are moved down from the top level
> tags
> trunk
> utilities
> whiteboard
>
>I'm not sure now is the right time to be moving trunk so I'd be willing
>to live with some inconsistency right now and just have
> blazeds
> branches
> external
> falcon
> import2
> site
> tags
> tlf
> trunk <-- this is the current top-level trunk
> utilities
> whiteboard
>
>Thoughts?
Regardless of whether falcon is top-level or under trunk, I think now is as good a time as any to go for your "I would like us to have" scenario since TLF will be arriving shortly. This is a very common Apache layout pattern. import2 should be deleted.
I think it is confusing if the branches and tags that apply to trunk are lost in the list. I am going to have to add a tags directory to the utilities directory when we release the Install tool (but I see there is a problem already in that directory structure since there are 3 directories under utilities that will all need to be tagged).
Carol
Re: Falcon location
Posted by Carol Frampton <cf...@adobe.com>.
On 8/14/12 2 :17PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 8/14/12 11:05 AM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> I'd like to start a discussion of where Falcon will live in the Apache
>> repository.
>>
>> The initial donation will be an Eclipse project and Ant scripts for
>>building
>> Falcon itself. Later we will donate another Eclipse project and Ant
>>scripts
>> for testing Falcon
>>
>> Although it is Java code, I don't think it should go into trunk/modules
>>with
>> the older compiler. It would be confusing to have a bunch of
>>subdirectories in
>> trunk/modules, some of which are for the old compiler and some of which
>>are
>> for the new compiler. So I propose that the two Falcon projects live
>>inside
>> trunk/falcon.
>>
>> Like the old compiler, Falcon is tied closely to the Flex framework
>>because of
>> the semantics of MXML. Therefore, I think Falcon belongs initially
>>"inside"
>> Flex, like the old compiler was inside Flex. Eventually, it would be
>> interesting to try break many of these dependencies and let Falcon
>>become its
>> own project independent of the framework, but I see that as longer-term
>> evolution.
>>
>> - Gordon
>>
>FWIW, keep in mind we also expect TLF to get VP signature this week as
>well
>and BlazeDS is in progress. IMO, All three are standalone entities and
>should have top-level project status. I don't know how hard it is to move
>the current trunk into an directory called sdk, but that would be my first
>choice as in, when you go here:
>https://svn.apache.org/repos/asf/incubator/flex/
>
>You currently see:
> branches
> external
> import2
> site
> tags
> trunk
> utilities
> whiteboard
>
>And I would like us to have:
> blazeds
> external
> falcon
> import2
> site
> tlf
> sdk
> branches <-- these 3 are moved down from the top level
> tags
> trunk
> utilities
> whiteboard
>
>I'm not sure now is the right time to be moving trunk so I'd be willing to
>live with some inconsistency right now and just have
> blazeds
> branches
> external
> falcon
> import2
> site
> tags
> tlf
> trunk <-- this is the current top-level trunk
> utilities
> whiteboard
>
>Thoughts?
Regardless of whether falcon is top-level or under trunk, I think now is
as good a time as any to go for your "I would like us to have" scenario
since TLF will be arriving shortly. This is a very common Apache layout
pattern. import2 should be deleted.
I think it is confusing if the branches and tags that apply to trunk are
lost in the list. I am going to have to add a tags directory to the
utilities directory when we release the Install tool (but I see there is a
problem already in that directory structure since there are 3 directories
under utilities that will all need to be tagged).
Carol
Re: Falcon location
Posted by Alex Harui <ah...@adobe.com>.
On 8/14/12 11:05 AM, "Gordon Smith" <go...@adobe.com> wrote:
> I'd like to start a discussion of where Falcon will live in the Apache
> repository.
>
> The initial donation will be an Eclipse project and Ant scripts for building
> Falcon itself. Later we will donate another Eclipse project and Ant scripts
> for testing Falcon
>
> Although it is Java code, I don't think it should go into trunk/modules with
> the older compiler. It would be confusing to have a bunch of subdirectories in
> trunk/modules, some of which are for the old compiler and some of which are
> for the new compiler. So I propose that the two Falcon projects live inside
> trunk/falcon.
>
> Like the old compiler, Falcon is tied closely to the Flex framework because of
> the semantics of MXML. Therefore, I think Falcon belongs initially "inside"
> Flex, like the old compiler was inside Flex. Eventually, it would be
> interesting to try break many of these dependencies and let Falcon become its
> own project independent of the framework, but I see that as longer-term
> evolution.
>
> - Gordon
>
FWIW, keep in mind we also expect TLF to get VP signature this week as well
and BlazeDS is in progress. IMO, All three are standalone entities and
should have top-level project status. I don't know how hard it is to move
the current trunk into an directory called sdk, but that would be my first
choice as in, when you go here:
https://svn.apache.org/repos/asf/incubator/flex/
You currently see:
branches
external
import2
site
tags
trunk
utilities
whiteboard
And I would like us to have:
blazeds
external
falcon
import2
site
tlf
sdk
branches <-- these 3 are moved down from the top level
tags
trunk
utilities
whiteboard
I'm not sure now is the right time to be moving trunk so I'd be willing to
live with some inconsistency right now and just have
blazeds
branches
external
falcon
import2
site
tags
tlf
trunk <-- this is the current top-level trunk
utilities
whiteboard
Thoughts?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui