flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: New Flex to JS project
Date Thu, 03 Jul 2014 05:57:21 GMT
Hi Igor,

Can you donate some of your FlexJS/Polymer code to Apache?  We've already
got the beginnings of Cordova, Jquery and CreateJS.  Polymer sounds like a
good addition.

Thanks,
-Alex

On 7/2/14 1:31 PM, "Igor Costa" <igorcosta@gmail.com> wrote:

>Erik
>
>Right now I'm on a stage of prove of concept using FlexJS and using
>Polymer
>as the output template. I made with success at least with a simple button.
>Polymer has similar architecture as Flex.
>
>Is there a way I can  share each other code? I'm not so familiar with
>vanila sdk.
>
>
>Best Regards
>
>----------------------------
>Igor Costa
>www.igorcosta.com
>www.igorcosta.org
>
>
>On Wed, Jul 2, 2014 at 4:59 PM, Nicholas Kwiatkowski <nicholas@spoon.as>
>wrote:
>
>> It's pretty much one command.  The same one you use to keep develop
>>current
>> with your branch :)
>>
>> -Nick
>>
>>
>> On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin <erik@ixsoftware.nl>
>>wrote:
>>
>> > On git: let's assume I work on these branches for 6 months (while
>>keeping
>> > them up to date with develop). How much of a hassle will it be to
>>merge
>> > them back into their respective 'develop' branches?
>> >
>> > EdB
>> >
>> >
>> >
>> > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <
>> bigosmallm@gmail.com
>> > >
>> > wrote:
>> >
>> > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
>> > christofer.dutz@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: omuppi1@gmail.com <omuppi1@gmail.com> im Auftrag von
>>OmPrakash
>> > > > Muppirala <bigosmallm@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 <erik@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.dutz@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 <erik@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.dutz@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 <erik@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
>> >
>>


Mime
View raw message