As soon as I know what steps there are, sure ;-) I'll create a guide to using this stuff. The idea is to keep it simple: nothing special required on the MXML/AS side (business as usual, vanilla Flex), with an FB 'External Tool' to launch the JS publishing. The Installer should be able to handle most of the client side setup. For developers, things should also be relatively straight forward: create a shim for an MX or Spark component in either one of the new namespaces and then focus on implementing it's public API in JS. "That's all" :-P
This will take substantial work on the FalconJX compiler, as I aim to use the Google Closure Tools to the max in the JS output and framework, and I plan to support only current versions of the major browsers, allowing me to do some ES5 and ES6 trickery ;-) EdB On Wed, Jul 2, 2014 at 3:53 PM, jude <flexcapaci...@gmail.com> wrote: > If applicable please add the steps you take to the wiki so others can know > how to get started as well. IE, something like this for setting up your > environment, > https://cwiki.apache.org/confluence/display/FLEX/1.+Setting+up+the+SDK. > There may be something added since I last checked. > > > On Wed, Jul 2, 2014 at 5:57 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: > > > Merge sounds like the way to go... Let's not revisit the whole Git usage > > thread(s) ;-) > > > > EdB > > > > > > > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala < > bigosma...@gmail.com > > > > > wrote: > > > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > You don't loose the history when rebasing ... you sort of serialize > it. > > > Ok > > > > the order of commits is messed up, but I never really care about > this. > > > > It might look less interesting in a GIT visualization tool where you > > > could > > > > see tons of different branches and merges, but it should be a lot > > easier > > > to > > > > maintain, as a serial history is definiely the one that causes the > > least > > > > trouble ;-) > > > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > > "Stash" > > > > and have never really had any problems. One click on "Update SCM" > and I > > > > still work on my featrue branch, but pull in all changes from develop > > or > > > > whatever branch I branched from. When it comes to commit, the commit > > > itself > > > > should be a fast-forward commit. > > > > > > > > But I guess there are several flavours here ... depending on the guy > > you > > > > ask or listen too, a different way will probably be recommended. I > > guess > > > > manually merging changes from develop to the feature branch is as > valid > > > as > > > > rebasing, but I think rebasing is easier and causes less trouble, but > > you > > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > > > Chris > > > > > > > > > > I will let Erik decide if he wants to rebase or merge. My > recommendation > > > is that, since it is a feature branch, it will be useful to retain the > > > commit history intact. So, merge makes sense. > > > > > > If Erik does not want to keep the commit history intact, rebase will > just > > > work fine. > > > > > > Thanks, > > > Om > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > Von: omup...@gmail.com <omup...@gmail.com> im Auftrag von OmPrakash > > > > Muppirala <bigosma...@gmail.com> > > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > > An: dev@flex.apache.org > > > > Betreff: Re: New Flex to JS project > > > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <e...@ixsoftware.nl> > > > wrote: > > > > > > > > > Ok, just checking: > > > > > > > > > > I create a local branch, let's call it 'vf2js', off > > 'origin/develop'. I > > > > > select this as my active branch. > > > > > > > > > > > > So far so good. > > > > > > > > > > > > > If I then 'rebase', all changes that have > > > > > been made to 'origin/develop' will be pulled into my local branch? > So > > > > far, > > > > > so good. > > > > > > > > > > > > Rebase at this point is not required. The code from origin/develop > is > > > > already in the 'vf2js' branch. You will need to 'merge' from > > > > origin/develop into vf2js once in a while to make sure that you are > in > > > sync > > > > with whats happening with origin/develop. When you are done with the > > > > feature, you just 'merge' vf2js into develop. If the history of the > > > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > > > so I 'publish' it. Is keeping the remote copy of my local branch up > > to > > > > date > > > > > just a question of 'pushing' all commits to that remote branch? > > > > > > > > > > > > Yes, that is correct. > > > > > > > > > > > > > Will > > > > > changes that come from the remote 'develop' via my local 'vf2js' > also > > > in > > > > > the remote 'vf2js' that way? > > > > > > > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > > > > christofer.d...@c-ware.de > > > > > > > > > > > wrote: > > > > > > > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > > > > Update, > > > > > > Apply Patch" ... if all goes well, it's just this one command, if > > > there > > > > > are > > > > > > conflicts, you get the usual conflict editor you would get anyway > > if > > > > you > > > > > > created conflicts on develop. > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > Von: Erik de Bruin <e...@ixsoftware.nl> > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > > > > > An: dev@flex.apache.org > > > > > > Betreff: Re: New Flex to JS project > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > Thanks for the feedback. > > > > > > > > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" > SWF > > > > > > compiler, the former is the Flex to JavaScript cross compiler. > > > > > > > > > > > > I guess a feature branch might work... But I'm afraid that > keeping > > > that > > > > > > branch up to date with the 'develop' branch will add extra work. > > How > > > to > > > > > > best handle that part, so I don't spend what little time I have > on > > > Git > > > > > > stuff instead of code? > > > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz < > > > > > christofer.d...@c-ware.de > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > I think the reason for the overlay is that by this we are > > tricking > > > > the > > > > > > > FlashBuilder to use Falcon instead of the old compiler. > > > > > > > It should be possible to have Falcon separate from the normal > > > > compiler. > > > > > > > It's just that FlashBuilder will probably not be albe to use it > > > that > > > > > way. > > > > > > > Probably IntelliJ would support this withn a few hours, > Flexmojos > > > > > within > > > > > > a > > > > > > > few weeks and FlashBuilder never ;-) > > > > > > > > > > > > > > You shouldn't implement this in the develop branch but create a > > > > > > > feature-branch instead that forks off the develop branch. This > > way > > > > your > > > > > > > changes are available to anyone interested and as soon as the > > > feature > > > > > is > > > > > > > finished, you merge it back to develop. > > > > > > > > > > > > > > Chris > > > > > > > ________________________________________ > > > > > > > Von: Erik de Bruin <e...@ixsoftware.nl> > > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > > > > > > An: dev@flex.apache.org > > > > > > > Betreff: New Flex to JS project > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm working on creating a way to publish vanilla Flex SDK > > projects > > > to > > > > > > > JavaScript on latest gen browsers. This project consists of > > several > > > > sub > > > > > > > projects, and I'm wondering what is the best way forward with > > > regard > > > > to > > > > > > > contributing them: > > > > > > > > > > > > > > 1) two new namespaces and accompanying projects in the main > Flex > > > SDK: > > > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim > objects > > > for > > > > > (you > > > > > > > guessed it) MX and Spark components. > > > > > > > > > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > > > > > > > > > > > 3) a new JavaScript library for the components and shims for AS > > > > classes > > > > > > > > > > > > > > 4) a testing framework for the JS components, loosely based on > > > > > Marmotinni > > > > > > > > > > > > > > Questions: > > > > > > > > > > > > > > A - I would very much like to work in the 'develop' branches of > > the > > > > > > > projects involved, but especially on the part of '1)' I'm not > > sure > > > > if I > > > > > > did > > > > > > > it right. All tests I can think of seem to pass, but maybe > > someone > > > > has > > > > > > the > > > > > > > time to do a code review on a branch that I can publish? > > > > > > > > > > > > > > B - In order for this to work, FalconJX needs to be part of the > > > > regular > > > > > > SDK > > > > > > > distribution. Folks who did this on the FlexJS overlay: what > does > > > it > > > > > take > > > > > > > to make FalconJX part of the SDK? > > > > > > > > > > > > > > That's it, for now :-) > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ix Multimedia Software > > > > > > > > > > > > > > Jan Luykenstraat 27 > > > > > > > 3521 VB Utrecht > > > > > > > > > > > > > > T. 06-51952295 > > > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ix Multimedia Software > > > > > > > > > > > > Jan Luykenstraat 27 > > > > > > 3521 VB Utrecht > > > > > > > > > > > > T. 06-51952295 > > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ix Multimedia Software > > > > > > > > > > Jan Luykenstraat 27 > > > > > 3521 VB Utrecht > > > > > > > > > > T. 06-51952295 > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > -- > > Ix Multimedia Software > > > > Jan Luykenstraat 27 > > 3521 VB Utrecht > > > > T. 06-51952295 > > I. www.ixsoftware.nl > > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
