Re: [FlexJS] Dual branch
> On Mar 16, 2017, at 6:54 PM, Alex Haruiwrote: > > > > On 3/16/17, 9:41 AM, "Harbs" wrote: > >> So, as soon as you merge in dual, all the $displayObject references and >> all will be gone. Correct? > > I actually haven't done that yet ($displayObject points to itself), but I > guess I should go and do that. It might be safer to do that later? >> >> Sounds scary. >> >> I’d like to test my app on the dual branch before you do the merge. I >> can’t afford a week of non-productivity right now. >> >> Can you wait until Sunday or Monday to merge to give me time to test? > > The merge won't happen for several days. I have to get through your > goog.require problem first, then I expect tons of conflicts. I’m glad to hear that. :-) Harbs
Re: [FlexJS] Dual branch
Ok Alex, thanks for clearing it 2017-03-16 18:49 GMT+01:00 Alex Harui: > > > On 3/16/17, 10:38 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > > wrote: > > >So, in order to understand what I'm missing, "Basic" will be in the > >diagram > >I did in place of "FlexJS"? > > > >In Core be should have things like UIBase, UIButtonBase, Container... > >since > >HTML (Div, H1, P...) will need it. > > > >Then in Basic we should have FlexJS set (i.e: js:Button, js:TextInput, > >js:CheckBox...) and Express will depend on Basic. > > > >At least that is the way I see it... > > > > Yes, will get there, but maybe after the merge. > > -Alex > > -- 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.
Re: [FlexJS] Dual branch
On 3/16/17, 10:38 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"wrote: >So, in order to understand what I'm missing, "Basic" will be in the >diagram >I did in place of "FlexJS"? > >In Core be should have things like UIBase, UIButtonBase, Container... >since >HTML (Div, H1, P...) will need it. > >Then in Basic we should have FlexJS set (i.e: js:Button, js:TextInput, >js:CheckBox...) and Express will depend on Basic. > >At least that is the way I see it... > Yes, will get there, but maybe after the merge. -Alex
Re: [FlexJS] Dual branch
So, in order to understand what I'm missing, "Basic" will be in the diagram I did in place of "FlexJS"? In Core be should have things like UIBase, UIButtonBase, Container... since HTML (Div, H1, P...) will need it. Then in Basic we should have FlexJS set (i.e: js:Button, js:TextInput, js:CheckBox...) and Express will depend on Basic. At least that is the way I see it... 2017-03-16 18:00 GMT+01:00 Alex Harui: > > > On 3/16/17, 9:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > wrote: > > >Hi Alex, > > > >2017-03-16 15:54 GMT+01:00 Alex Harui : > > > >> > >> The components in the HTML project that are not direct wrappers (like A, > >> Div, H1, etc) now live in the Basic folder. HTML will just contain > >>these > >> direct wrappers. > >> > > > >it's strange for me that refactor. I proposed just some time ago that HTML > >should have all tags that are html (Div, A, P, H1,...) and nothing more, > >HTML should depend on Core, then we should have CreateJS, MDL,...and > >FlexJS > >set (Express). This latest one should be where we'll concentrate efforts. > > > >Core --- HTML. - CreateJS > > -- MDL > > -- FlexJS (Buttom, TextInput, Container...) > > ThemeX > > > > -ThemeY > > > >In this way we could avoid CSS defaults in the rest of non-flexjs > >implementations that right now affects that efforts. As well HTML should > >not impose any defaults (position relative or things like that hard coded > >in classes) > > > >Makes this sense? > > I think I'm doing what you wanted. If not, I think it is a step closer > and we can make more changes after the merge, such as moving UIBase back > to Core. Currently in "develop" both HTML and Basic have a different > version of UIBase. > > Regarding CSS defaults, after the merge we can see if other refactoring is > needed so that MDL doesn't have dependencies on Basic. > > Thanks, > -Alex > > -- 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.
Re: [FlexJS] Dual branch
On 3/16/17, 9:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"wrote: >Hi Alex, > >2017-03-16 15:54 GMT+01:00 Alex Harui : > >> >> The components in the HTML project that are not direct wrappers (like A, >> Div, H1, etc) now live in the Basic folder. HTML will just contain >>these >> direct wrappers. >> > >it's strange for me that refactor. I proposed just some time ago that HTML >should have all tags that are html (Div, A, P, H1,...) and nothing more, >HTML should depend on Core, then we should have CreateJS, MDL,...and >FlexJS >set (Express). This latest one should be where we'll concentrate efforts. > >Core --- HTML. - CreateJS > -- MDL > -- FlexJS (Buttom, TextInput, Container...) > ThemeX > > -ThemeY > >In this way we could avoid CSS defaults in the rest of non-flexjs >implementations that right now affects that efforts. As well HTML should >not impose any defaults (position relative or things like that hard coded >in classes) > >Makes this sense? I think I'm doing what you wanted. If not, I think it is a step closer and we can make more changes after the merge, such as moving UIBase back to Core. Currently in "develop" both HTML and Basic have a different version of UIBase. Regarding CSS defaults, after the merge we can see if other refactoring is needed so that MDL doesn't have dependencies on Basic. Thanks, -Alex
Re: [FlexJS] Dual branch
On 3/16/17, 9:41 AM, "Harbs"wrote: >So, as soon as you merge in dual, all the $displayObject references and >all will be gone. Correct? I actually haven't done that yet ($displayObject points to itself), but I guess I should go and do that. > >Sounds scary. > >I’d like to test my app on the dual branch before you do the merge. I >can’t afford a week of non-productivity right now. > >Can you wait until Sunday or Monday to merge to give me time to test? The merge won't happen for several days. I have to get through your goog.require problem first, then I expect tons of conflicts. Thanks, -Alex
Re: [FlexJS] Dual branch
Hi Alex, 2017-03-16 15:54 GMT+01:00 Alex Harui: > > The components in the HTML project that are not direct wrappers (like A, > Div, H1, etc) now live in the Basic folder. HTML will just contain these > direct wrappers. > it's strange for me that refactor. I proposed just some time ago that HTML should have all tags that are html (Div, A, P, H1,...) and nothing more, HTML should depend on Core, then we should have CreateJS, MDL,...and FlexJS set (Express). This latest one should be where we'll concentrate efforts. Core --- HTML. - CreateJS -- MDL -- FlexJS (Buttom, TextInput, Container...) ThemeX -ThemeY In this way we could avoid CSS defaults in the rest of non-flexjs implementations that right now affects that efforts. As well HTML should not impose any defaults (position relative or things like that hard coded in classes) Makes this sense? thanks -- Carlos Rovira http://about.me/carlosrovira
Re: [FlexJS] Dual branch
So, as soon as you merge in dual, all the $displayObject references and all will be gone. Correct? Sounds scary. I’d like to test my app on the dual branch before you do the merge. I can’t afford a week of non-productivity right now. Can you wait until Sunday or Monday to merge to give me time to test? Harbs > On Mar 16, 2017, at 4:54 PM, Alex Haruiwrote: > > > > On 3/16/17, 12:37 AM, "Harbs" wrote: > >> I have not had the time. >> >> Is there anything to be aware of when you merge it in from an application >> development stand-point? > > I was sort of wondering if it would compile a big app and produce a valid > SWF and whether it would miss errors or report false-positives. > >> >> Have you done anything regarding the Basic vs. HTML projects? > > The components in the HTML project that are not direct wrappers (like A, > Div, H1, etc) now live in the Basic folder. HTML will just contain these > direct wrappers. > > Thanks, > -Alex >
Re: [FlexJS] Dual branch
On 3/16/17, 12:37 AM, "Harbs"wrote: >I have not had the time. > >Is there anything to be aware of when you merge it in from an application >development stand-point? I was sort of wondering if it would compile a big app and produce a valid SWF and whether it would miss errors or report false-positives. > >Have you done anything regarding the Basic vs. HTML projects? The components in the HTML project that are not direct wrappers (like A, Div, H1, etc) now live in the Basic folder. HTML will just contain these direct wrappers. Thanks, -Alex
Re: [FlexJS] Dual branch
I have not had the time. Is there anything to be aware of when you merge it in from an application development stand-point? Have you done anything regarding the Basic vs. HTML projects? Harbs > On Mar 16, 2017, at 3:01 AM, Alex Haruiwrote: > > Has anyone else looked at the dual branch? If you want to know more about > it before it gets merged let me know soon, otherwise I am going to merge > it. > > Thanks, > -Alex > > On 3/11/17, 10:49 PM, "Alex Harui" wrote: > >> >> >> On 3/11/17, 10:34 AM, "Christofer Dutz" wrote: >> >>> Hi Alex, >>> >>> I just had a look and the changes look valid. The only thing I think I >>> should change, is that it seems as if prior to your change, I needed two >>> compilations AS & JS and therefore there were two Mojos: CompileASMojo >>> and CompileJSMojo. I think now we need only one. If the current state it >>> also looks as if both the AS and the JS mojo would do a dual compilation. >>> >>> If you confirm, that now I need only one Mojo, I would refactor it and >>> create a “CompileLibMojo” and remove the other two CompileASMojo and >>> CompileJSMojo. >> >> Well, we still build two SWCs per project. We might want to rename the >> Mojos, but the CompileASMojo builds a SWC that has a library.swf with >> COMPILE::SWF=true but includes JS files compiled with COMPILE::JS=true, >> then CompileJSMojo builds a SWC that has a library.swf with >> COMPILE::JS=true and the JS files with COMPILE::JS=true and the artifact >> has the -js classifier. >> >> At some point we can try combining the two and renaming one of the >> library.swf and catalog.xml files, but for now we still need a SWC with >> library.swf with COMPILE::SWF=true and a SWC with library.swf with >> COMPILE::JS=true. >> >> Thanks, >> -Alex >> >
Re: [FlexJS] Dual branch
Has anyone else looked at the dual branch? If you want to know more about it before it gets merged let me know soon, otherwise I am going to merge it. Thanks, -Alex On 3/11/17, 10:49 PM, "Alex Harui"wrote: > > >On 3/11/17, 10:34 AM, "Christofer Dutz" wrote: > >>Hi Alex, >> >>I just had a look and the changes look valid. The only thing I think I >>should change, is that it seems as if prior to your change, I needed two >>compilations AS & JS and therefore there were two Mojos: CompileASMojo >>and CompileJSMojo. I think now we need only one. If the current state it >>also looks as if both the AS and the JS mojo would do a dual compilation. >> >>If you confirm, that now I need only one Mojo, I would refactor it and >>create a “CompileLibMojo” and remove the other two CompileASMojo and >>CompileJSMojo. > >Well, we still build two SWCs per project. We might want to rename the >Mojos, but the CompileASMojo builds a SWC that has a library.swf with >COMPILE::SWF=true but includes JS files compiled with COMPILE::JS=true, >then CompileJSMojo builds a SWC that has a library.swf with >COMPILE::JS=true and the JS files with COMPILE::JS=true and the artifact >has the -js classifier. > >At some point we can try combining the two and renaming one of the >library.swf and catalog.xml files, but for now we still need a SWC with >library.swf with COMPILE::SWF=true and a SWC with library.swf with >COMPILE::JS=true. > >Thanks, >-Alex >
Re: [FlexJS] Dual branch
On 3/11/17, 10:34 AM, "Christofer Dutz"wrote: >Hi Alex, > >I just had a look and the changes look valid. The only thing I think I >should change, is that it seems as if prior to your change, I needed two >compilations AS & JS and therefore there were two Mojos: CompileASMojo >and CompileJSMojo. I think now we need only one. If the current state it >also looks as if both the AS and the JS mojo would do a dual compilation. > >If you confirm, that now I need only one Mojo, I would refactor it and >create a “CompileLibMojo” and remove the other two CompileASMojo and >CompileJSMojo. Well, we still build two SWCs per project. We might want to rename the Mojos, but the CompileASMojo builds a SWC that has a library.swf with COMPILE::SWF=true but includes JS files compiled with COMPILE::JS=true, then CompileJSMojo builds a SWC that has a library.swf with COMPILE::JS=true and the JS files with COMPILE::JS=true and the artifact has the -js classifier. At some point we can try combining the two and renaming one of the library.swf and catalog.xml files, but for now we still need a SWC with library.swf with COMPILE::SWF=true and a SWC with library.swf with COMPILE::JS=true. Thanks, -Alex
Re: [FlexJS] Dual branch
Hi Alex, I just had a look and the changes look valid. The only thing I think I should change, is that it seems as if prior to your change, I needed two compilations AS & JS and therefore there were two Mojos: CompileASMojo and CompileJSMojo. I think now we need only one. If the current state it also looks as if both the AS and the JS mojo would do a dual compilation. If you confirm, that now I need only one Mojo, I would refactor it and create a “CompileLibMojo” and remove the other two CompileASMojo and CompileJSMojo. Chris Am 10.03.17, 17:59 schrieb "Alex Harui": On 3/10/17, 7:17 AM, "Christofer Dutz" wrote: >Hi Alex, > >So I adjusted the native examples poms in your dual branch … now it seems >to build successfully with maven. Great! Thanks. Have you looked over the changes I made to the mojos? I'd like to merge this branch soon. Thanks, -Alex
Re: [FlexJS] Dual branch
On 3/10/17, 7:17 AM, "Christofer Dutz"wrote: >Hi Alex, > >So I adjusted the native examples poms in your dual branch … now it seems >to build successfully with maven. Great! Thanks. Have you looked over the changes I made to the mojos? I'd like to merge this branch soon. Thanks, -Alex
Re: [FlexJS] Dual branch
Hi Alex, So I adjusted the native examples poms in your dual branch … now it seems to build successfully with maven. Chris Am 07.03.17, 17:29 schrieb "Alex Harui": On 3/7/17, 4:36 AM, "Christofer Dutz" wrote: >Hi guys and especially Alex, > >I would like to ask you to give a short summary at what you changed in >the dual branch. I don’t quite know as to what I should be looking for to >make Maven support to match. > >Could you please summarize what new compiler options/arguments, which >new/changed/obsolete compilation runs and how the packaging should have >changed? >Right now, I still see swc and js-swc as output of the compilation. I >would expect one single swc to come out and this to contain two >catalog.xml … ist that correct? The goal of dual was just to get two "stacks" of SWCs (one for SWF, one for JS) to work in the compiler. Merging the two swcs into one and renaming catalog.xml and library.swf is for later. Getting two "stacks" to work sets the foundation for merging later by first proving that we can in fact produce runnable SWFs and JS from separate stacks and that having two stacks allows us to find platform dependencies in our code. So, there are still two SWCs produced from each frameworks/projects folder. However, instead of calling the JS oriented one a "typedefs" SWC, I changed it to be a "js" classifier because the JS swc is now used to build the JS app. Before, the JS-oriented SWC was primarily used to generate downstream JS-oriented SWCs so the "typedefs" classifier made more sense. The default SWC is the same as before. It contains a library.swf compiled with COMPILE::SWF,true and thus the code inside is used for linking into SWFs. It contains the cross-complled JS output like before which was compiled with COMPILE::JS,true. And it contains any defaults.css like before. The "js" SWC is a bit different. It contains a library.swf compiled with COMPILE::JS,true just like before, but now it also contains the cross-compiled JS output (with COMPILE::JS, true) and any defaults.css. So it is more of a peer of the main SWC, it just has a different library.swf. In order to do this, I still use CompileASMojo to build the default SWC. I think the main changes there are that I switched the name of compile-as-config.xml to compile-swf-config.xml, but more importantly, I switched the mojo to use the FlexJS version of compc because the compc from compiler-jx now can produce both SWF and JS output (by calling the compc from the compiler folder for SWF output). So, CompileASMojo also learned how to filter artifacts and sort the js ones into js slots in the -config.xml file. The CompileJSMojo also now uses the compc from compiler-ix and filters artifacts a bit differently to produce the "js" swc. Then, once the framework is built, the CompileAppMojo now only needs one default execution since it now calls the compiler-ix version of MXMLC (MXMLJSC) which also now knows how to build both a SWF and JS output in one execution. So I took the second execution that had outputJavaScript=true out of the pom.xml. The main new compiler option is -compiler.targets which takes a set of strings like "SWF, "JSFlex", "JS", "JSNode". You can set compiler.targets to one or more of these to dictate what output you want. Then in order to support that, lots of existing options got platform-specific options so there is now a js-external-library-path and swf-external-library-path as well as the old external-library-path option. That way you can specify one -config.xml file for all output targets. I have essential obsoleted the -js-output-type parameter. Folks should use -compiler.targets instead for building SWCs and apps. Js-output-type is still used by ASDoc though. I think that's about it, although I'm sure I forgot to mention something. I won't be too surprised if I did something that isn't with the Maven philosophy. My main goal was to get MXMLJSC to output both SWF and JS so it would work better with most IDEs since most IDEs only know how to launch one compiler. And that has nothing to do with Maven. But once I got that working I decided that maybe Maven would prefer to have both outputs from one execution as well. HTH, -Alex > >Thanks in advance, > Chris
Re: [FlexJS] Dual branch
On 3/7/17, 4:36 AM, "Christofer Dutz"wrote: >Hi guys and especially Alex, > >I would like to ask you to give a short summary at what you changed in >the dual branch. I don’t quite know as to what I should be looking for to >make Maven support to match. > >Could you please summarize what new compiler options/arguments, which >new/changed/obsolete compilation runs and how the packaging should have >changed? >Right now, I still see swc and js-swc as output of the compilation. I >would expect one single swc to come out and this to contain two >catalog.xml … ist that correct? The goal of dual was just to get two "stacks" of SWCs (one for SWF, one for JS) to work in the compiler. Merging the two swcs into one and renaming catalog.xml and library.swf is for later. Getting two "stacks" to work sets the foundation for merging later by first proving that we can in fact produce runnable SWFs and JS from separate stacks and that having two stacks allows us to find platform dependencies in our code. So, there are still two SWCs produced from each frameworks/projects folder. However, instead of calling the JS oriented one a "typedefs" SWC, I changed it to be a "js" classifier because the JS swc is now used to build the JS app. Before, the JS-oriented SWC was primarily used to generate downstream JS-oriented SWCs so the "typedefs" classifier made more sense. The default SWC is the same as before. It contains a library.swf compiled with COMPILE::SWF,true and thus the code inside is used for linking into SWFs. It contains the cross-complled JS output like before which was compiled with COMPILE::JS,true. And it contains any defaults.css like before. The "js" SWC is a bit different. It contains a library.swf compiled with COMPILE::JS,true just like before, but now it also contains the cross-compiled JS output (with COMPILE::JS, true) and any defaults.css. So it is more of a peer of the main SWC, it just has a different library.swf. In order to do this, I still use CompileASMojo to build the default SWC. I think the main changes there are that I switched the name of compile-as-config.xml to compile-swf-config.xml, but more importantly, I switched the mojo to use the FlexJS version of compc because the compc from compiler-jx now can produce both SWF and JS output (by calling the compc from the compiler folder for SWF output). So, CompileASMojo also learned how to filter artifacts and sort the js ones into js slots in the -config.xml file. The CompileJSMojo also now uses the compc from compiler-ix and filters artifacts a bit differently to produce the "js" swc. Then, once the framework is built, the CompileAppMojo now only needs one default execution since it now calls the compiler-ix version of MXMLC (MXMLJSC) which also now knows how to build both a SWF and JS output in one execution. So I took the second execution that had outputJavaScript=true out of the pom.xml. The main new compiler option is -compiler.targets which takes a set of strings like "SWF, "JSFlex", "JS", "JSNode". You can set compiler.targets to one or more of these to dictate what output you want. Then in order to support that, lots of existing options got platform-specific options so there is now a js-external-library-path and swf-external-library-path as well as the old external-library-path option. That way you can specify one -config.xml file for all output targets. I have essential obsoleted the -js-output-type parameter. Folks should use -compiler.targets instead for building SWCs and apps. Js-output-type is still used by ASDoc though. I think that's about it, although I'm sure I forgot to mention something. I won't be too surprised if I did something that isn't with the Maven philosophy. My main goal was to get MXMLJSC to output both SWF and JS so it would work better with most IDEs since most IDEs only know how to launch one compiler. And that has nothing to do with Maven. But once I got that working I decided that maybe Maven would prefer to have both outputs from one execution as well. HTH, -Alex > >Thanks in advance, > Chris