Hi Chris, Those three parts seems ok to me.
Thanks for asking 2016-07-11 9:08 GMT+02:00 Harbs <harbs.li...@gmail.com>: > One nitpick here: > > falcon contains both the falcon and falconjx compiler. Are both considered > “FlexJS”? > > On Jul 11, 2016, at 9:59 AM, Christofer Dutz <christofer.d...@c-ware.de> > wrote: > > > So are we agreeing on splitting up our codebase into these three parts > (even if two of the repos currently still have different names)? > > > > - flexjs-compiler > > > > - flexjs-typedefs > > > > - flexjs-framework > > > > > > In this case I could start preparing things by renaming the "extern" > stuff to "typedef"? I would also call the Maven classifier "typedef". Are > the JSSWCs from the asjs bundle typedefs or are they something different? > > > > > > Chris > > > > ________________________________ > > Von: carlos.rov...@gmail.com <carlos.rov...@gmail.com> im Auftrag von > Carlos Rovira <carlos.rov...@codeoscopic.com> > > Gesendet: Sonntag, 10. Juli 2016 17:34:59 > > An: dev@flex.apache.org > > Cc: Christofer Dutz > > Betreff: Re: AW: [FlexJS][Falcon] Some final moving around of stuff :-) > > > > Hi, > > > > +1 > > > > I think is completely the way to go, without doubt. These are the kind > of things that needs to be refactored in order to get maven to build in > order and correcly without problems (like circular dependencies, > chicken-egg problems, and so on...), and this kind of things use to be a > the way maven signal things needs to be moved. > > > > > > 2016-07-10 16:01 GMT+02:00 Alex Harui <aha...@adobe.com<mailto: > aha...@adobe.com>>: > > Version number is a whole different topic. Because the extern defines > existing third-party apis there is a good chance they won't change as often. > > > > Sent from my LG G3, an AT&T 4G LTE smartphone > > > > ------ Original message------ > > From: Christofer Dutz > > Date: Sun, Jul 10, 2016 3:26 AM > > To: dev@flex.apache.org<mailto:dev@flex.apache.org>; > > Subject:AW: [FlexJS][Falcon] Some final moving around of stuff :-) > > > > I would particularly like the renaming to flexjs-framework and > FlexJS-compiler :-) > > > > We would have to do and vote on 3 releases, but I guess that should be > easy. I would however suggest to keep the versions in sync. Everything else > would confuse people. > > > > Chris > > > > > > > > Von meinem Samsung Galaxy Smartphone gesendet. > > > > > > -------- Ursprüngliche Nachricht -------- > > Von: Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>> > > Datum: 10.07.16 06:38 (GMT+01:00) > > An: dev@flex.apache.org<mailto:dev@flex.apache.org> > > Betreff: Re: [FlexJS][Falcon] Some final moving around of stuff :-) > > > > I was going to suggest this option. > > > > Externs are something which might or might not be used with the > Framework. Having it a separate repo makes it clear that it’s a third piece > of “FlexJS” (i.e. FlexJS Compiler, FlexJS Framework and FlexJS Type > Definitions). In fact, I would vote to name the repo flex-typedefs or > flex-js-typedefs. > > > > On Jul 9, 2016, at 6:12 PM, Alex Harui <aha...@adobe.com<mailto: > aha...@adobe.com>> wrote: > > > >> Getting a flex-extern repo is also an option. > >> > >> Sent from my LG G3, an AT&T 4G LTE smartphone > >> > >> ------ Original message------ > >> From: Christofer Dutz > >> Date: Sat, Jul 9, 2016 7:54 AM > >> To: dev@flex.apache.org<mailto:dev@flex.apache.org>; > >> Subject:AW: [FlexJS][Falcon] Some final moving around of stuff :-) > >> > >> Hi Alex, > >> > >> Well fire me they are sumthing in between falcon and asjs. My main > reason for wanting to move them us that it would completely untangle the > dependencies and make the build trivial. > >> > >> Chris > >> > >> > >> > >> Von meinem Samsung Galaxy Smartphone gesendet. > >> > >> > >> -------- Ursprüngliche Nachricht -------- > >> Von: Alex Harui <aha...@adobe.com<mailto:aha...@adobe.com>> > >> Datum: 09.07.16 16:32 (GMT+01:00) > >> An: dev@flex.apache.org<mailto:dev@flex.apache.org> > >> Betreff: Re: [FlexJS][Falcon] Some final moving around of stuff :-) > >> > >> > >> > >> On 7/8/16, 2:04 PM, "Christofer Dutz" <christofer.d...@c-ware.de > <mailto:christofer.d...@c-ware.de>> wrote: > >> > >>> Hi, > >>> > >>> > >>> ok in order to prepare the stage for a 0.7.0 release of Falcon and > ASJS, > >>> I would like to propose some final moving around of things. I would > like > >>> to move the "externs" to the ASJS project. For me the ASJS project is > >>> sort of a synonym for "framework" > >>> > >>> > >>> The reason for this is actually two: > >>> > >>> 1. For me Falcon is the "compiler" and Externs are somewhat the output > of > >>> the compiler. For me the externs are just part of the "framework" > (After > >>> all they are located in the "framework" directory in the end) > >>> > >>> 2. It makes the Build and hereby the Maven release process a lot easier > >>> as it could performed in one instead of two separate steps (first the > >>> compiler and then the externs) > >>> > >>> > >>> If we move the externs to the "framework" then we will be in the > position > >>> to do a simple "mvn clean install" in the "compiler" to build the > >>> compiler and all that belongs to it and we could to a "mvn clean > install" > >>> in the "framework" to build the SWCs and assemble a useable SDK. > >>> > >>> > >>> The reason for me investing a little more in this, is that in contrast > to > >>> having a binary release in our repo, as soon as we do a Maven release, > >>> taking it back isn't possible anymore. So I'd like to have things clean > >>> and not push stuff that we know will have to change soon. Especially if > >>> these changes are easy to implement now. > >>> > >>> > >>> I am not really happy with the names of the artifacts in the compiler > >>> module, but I'd be happy for now if we could do this untangling of the > >>> "externs". > >>> > >>> > >>> What do the others think? Do you agree that the Externs should be moved > >>> to the "framework"? > >>> > >> > >> I'd like to hear from a few others before we do this move. I don't > >> remember if there is some "packaging" reason like the ability to some > day > >> make a release just from flex-falcon that can create NativeJS apps. > >> > >> The Externs aren't a perfect fit for flex-asjs since they mostly aren't > >> AS. And the main set of externs comes packaged with the Google Closure > >> Compiler so that would mean the flex-asjs build would now also have to > >> bring down and/or unpack GCC. > >> > >> I can go either way. > >> -Alex > >> > > > > > > > > > > -- > > [ > http://www.codeoscopic.com/wp-content/uploads/2016/05/logo_codeoscopic_170x70t.png > ] > > Carlos Rovira > > Director General > > M: +34 607 22 60 05 > > http://www.codeoscopic.com > > http://www.avant2.es<http://www.avant2.es/> > > > > > > > > Este mensaje se dirige exclusivamente a su destinatario y puede contener > información privilegiada o confidencial. Si ha recibido este mensaje por > error, le rogamos que nos lo comunique inmediatamente por esta misma vía y > proceda a su destrucción. > > > > De la vigente Ley Orgánica de Protección de Datos (15/1999), le > comunicamos que sus datos forman parte de un fichero cuyo responsable es > CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la > prestación del servicio o información solicitados, teniendo usted derecho > de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose > a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la > documentación necesaria. > > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
