You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2017/03/07 12:36:21 UTC
[FlexJS] Dual branch
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?
Thanks in advance,
Chris
AW: [FlexJS] Dual branch
Posted by Christofer Dutz <ch...@c-ware.de>.
so i understand it correctly in the dual branch, the compiler produces one swc per type? And if you do pure js you use the js-swcs and if flash, you use the normal swcs?
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: Alex Harui <ah...@adobe.com>
Datum: 15.03.17 21:01 (GMT-05:00)
An: dev@flex.apache.org
Betreff: 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" <ah...@adobe.com> wrote:
>
>
>On 3/11/17, 10:34 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Ok Alex, thanks for clearing it
2017-03-16 18:49 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 3/16/17, 10:38 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/16/17, 10:38 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> 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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ah...@adobe.com>:
>
>
> On 3/16/17, 9:44 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Alex,
> >
> >2017-03-16 15:54 GMT+01:00 Alex Harui <ah...@adobe.com>:
> >
> >>
> >> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/16/17, 9:44 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>2017-03-16 15:54 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>>
>> 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
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
2017-03-16 15:54 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
> 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
Posted by Harbs <ha...@gmail.com>.
> On Mar 16, 2017, at 6:54 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/16/17, 9:41 AM, "Harbs" <ha...@gmail.com> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/16/17, 9:41 AM, "Harbs" <ha...@gmail.com> 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
Posted by Harbs <ha...@gmail.com>.
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 Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/16/17, 12:37 AM, "Harbs" <ha...@gmail.com> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/16/17, 12:37 AM, "Harbs" <ha...@gmail.com> 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
Posted by Harbs <ha...@gmail.com>.
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 Harui <ah...@adobe.com> wrote:
>
> 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" <ah...@adobe.com> wrote:
>
>>
>>
>> On 3/11/17, 10:34 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Alex Harui <ah...@adobe.com>.
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" <ah...@adobe.com> wrote:
>
>
>On 3/11/17, 10:34 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/11/17, 10:34 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ah...@adobe.com>:
On 3/10/17, 7:17 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/10/17, 7:17 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ah...@adobe.com>:
On 3/7/17, 4:36 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/7/17, 4:36 AM, "Christofer Dutz" <ch...@c-ware.de> 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