Hi Alex,
sorry for not responding on that last email ☹... must have missed that one ☹
For the general functionality of the flex-tool-groups, I simply use the basic
Java service registry functionality.
This allows to lookup a list of instances with a symbolic name. You can add
more implementations to the list, by providing a jar with a simple text file
named: “META-INF/services/org.apache.flex.tools.FlexToolGroup”. This file only
contains class names. Each row will be treated as an alternate implementation.
So if I want to get all “tool-groups”, all I have to do, is to ask the Service
registry to give me all “org.apache.flex.tools.FlexToolGroup”.
In my case I made sure I defined a universal interface that all implementations
would implement, so I know that I can simply cast each instance I get back to
that base interface.
In my case in order to add a new compiler called “foo”, all I would do, is to
add a jar with a class implementing FlexToolGroup and to make “getName” return
“foo”.
Currently I would have to extend the Enum JSOutputType to support “foo”, which
doesn’t make it that extensible.
Right now I have a template for each type of compilation and a matching “Mojo”.
All compiler options go into the configuration file for that particular Mojo.
Additionally, the Mojo is able to customize the default values used to generate
the template. For example, the getDefines method returns different values for
CompileASMojo and for CompileJSMojo.
All I have to do then, is to provide the template path to the compiler using
the default “execute” method of any of the “FlexTool” implementations and
simply provide an array of Strings which equals the normal array of Strings the
compiler gets in the Ant world.
Hope that explains things a little more.
Chris
Am 02.12.16, 19:13 schrieb "Alex Harui" <aha...@adobe.com>:
I'm about to start working on this. I haven't actually tried anything
yet, but my thinking is that there are some interesting issues regarding
configuration. Typically, when compiling an application, you define a
bunch of compiler options, but for a compilation that should produce two
different outputs, you might need two different sets of compiler options.
How should that be managed?
For example, you might want a different library-path for the SWF compile
vs the JS compile. Or set COMPILE::SWF=true for the SWF build and
COMPILE::SWF=false for the JS compile.
One possibility is that all platform-specific options have to be specified
in -config.xml files and not on the command line. Then for any
-load-config option, the JS compile will look for a js-prefixed file. So
instead of using compile-as-config.xml and compile-js-config.xml, we would
use compile-config.xml and js-compile-config.mxml and you would specify
-load-config=compile-config.xml as the compiler option.
Another possibility is that the SWF compile would always set
COMPILE::SWF=true and COMPILE::JS=false and the JS compile would do the
opposite. The JS compile would see if -js-library-path was specified and
if not, use the -library-path. The weird thing about this approach is
that the SWF compiler needs to support a -js-library-path option otherwise
the SWF compiler's configuration checker will throw an error. Adding
options that the SWF compiler must ignore doesn't seem right to me.
Any other ideas? Thoughts?
-Alex
On 10/7/16, 8:09 AM, "Alex Harui" <aha...@adobe.com> wrote:
>I don't know enough about how Flex Tool Groups work to form an opinion.
>Can you provide more details and explain how folks would configure things
>on the command-line?
>
>AIUI, -js-output-type is sort of overloaded right now, because the
>FLEXJS_DUAL dictates the output of a SWF. In my plan to combine things, I
>would introduce a new configuration parameter like -output-type or
>-targets or something like that. I supposed it could be a list of
>compiler jars to run. But -js-output-type doesn't currently go through
>different jars for JSC, NODE, and FLEXJS. That parameter just sets up a
>few configuration changes within the output classes.
>
>I'm pretty sure Schmalle imagined a true plug-in architecture for the
>emitters as well. Not sure we want to take all of that on right now, but
>we might want to consider that as well.
>
>-Alex
>
>On 10/7/16, 12:14 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>
>>I would like to propose a different approach:
>>
>>
>>Unless these approaches led to a dead end and there is no solution down
>>that path, I would rather suggest to refactor the compiler to allow
>>dynamic adding of alternate compilers. Currently the supported compilers
>>are limited by the JsOutputType enum. If we however used something like
>>the Java service thing I used for the Flex Tool Groups, we could allow
>>new experiments to start in dedicated Jars and we wouldn't have such a
>>mixture in case someone wants to try something out.
>>
>>
>>Chris
>>
>>________________________________
>>Von: Alex Harui <aha...@adobe.com>
>>Gesendet: Freitag, 7. Oktober 2016 00:25:30
>>An: dev@flex.apache.org
>>Betreff: Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
>>[FalconJX][FlexJS] COMPJSC and Build order)
>>
>>+1. Bonus points for making a tag and/or branch before deleting.
>>
>>-Alex
>>
>>On 10/6/16, 3:02 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>
>>>Makes sense to me. I say we simply delete it. No need to transfer to
>>>another folder. It'll still be in the repository's history.
>>>
>>>- Josh
>>>
>>>On Thu, Oct 6, 2016 at 2:55 PM, Carlos Rovira
>>><carlos.rov...@codeoscopic.com
>>>> wrote:
>>>
>>>> I want to propose the same. I something was an experiment and is no
>>>>more
>>>> developed. I think it should go to some folder that make people avoid
>>>> confusion about what code is valid and what is left behind.
>>>>
>>>> 2016-10-06 23:12 GMT+02:00 Christofer Dutz
>>>><christofer.d...@c-ware.de>:
>>>>
>>>> > I stumble over tons of VF2JS classes and think it would be better to
>>>>move
>>>> > stuf like that to some sort of attic. What do you think?
>>>> >
>>>> >
>>>> > Chris
>>>> >
>>>> > ________________________________
>>>> > Von: Josh Tynjala <joshtynj...@gmail.com>
>>>> > Gesendet: Donnerstag, 6. Oktober 2016 17:13:49
>>>> > An: dev@flex.apache.org
>>>> > Betreff: Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
>>>> > [FalconJX][FlexJS] COMPJSC and Build order)
>>>> >
>>>> > JSC is meant to be purely an ActionScript to JavaScript transpiler
>>>> without
>>>> > any frameworks. By default, it doesn't export an HTML file, but it
>>>>will
>>>> > optionally support custom HTML templates in 0.8.0. It is exposed
>>>>through
>>>> > the js/bin/asjsc executable, where it loads the
>>>>frameworks/js-config.xml
>>>> > configuration. js-config.xml references js.swc to give ActionScript
>>>> access
>>>> > to browser APIs.
>>>> >
>>>> > NODE generates an index.js that bootstraps things for Node.js. It is
>>>> > exposed through the js/bin/asnodec executable, which it loads the
>>>> > frameworks/node-config.xml configuration. In addition to js.swc,
>>>> > node-config.xml references node.swc to give ActionScript access to
>>>> Node.js
>>>> > APIs.
>>>> >
>>>> > As far as I know, AMD and VF2JS are no longer maintained. I assume
>>>>AMD
>>>> > tried to output AMD modules instead of goog modules. I remember Alex
>>>>or
>>>> > someone mentioning that VF2JS had something to do with the original
>>>>Flex
>>>> > framework, but I don't know the details.
>>>> >
>>>> > - Josh
>>>> >
>>>> > On Thu, Oct 6, 2016 at 12:10 AM, Christofer Dutz <
>>>> > christofer.d...@c-ware.de>
>>>> > wrote:
>>>> >
>>>> > > Hi Alex,
>>>> > >
>>>> > >
>>>> > > yesterday I stumbled over this flexjs-dual output type while
>>>>looking
>>>> for
>>>> > > the correct settings to buid a pure JS app. Would it be possible
>>>>for
>>>> you
>>>> > > guys to give a short summary of what the different output types
>>>> actually
>>>> > > are? The enum doesn't contain any documentation on this and I
>>>>guess
>>>> this
>>>> > > would be really helpful.
>>>> > >
>>>> > >
>>>> > > So far I see these output types:
>>>> > >
>>>> > > AMD
>>>> > > FLEXJS
>>>> > > GOOG
>>>> > > VF2JS
>>>> > > FLEXJS_DUAL
>>>> > > JSC
>>>> > > NODE
>>>> > >
>>>> > > And I guess I only used no value and FLEXJS
>>>> > >
>>>> > >
>>>> > > Chris
>>>> > >
>>>> > > ________________________________
>>>> > > Von: Alex Harui <aha...@adobe.com>
>>>> > > Gesendet: Donnerstag, 6. Oktober 2016 07:45:48
>>>> > > An: dev@flex.apache.org
>>>> > > Betreff: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
>>>> > > [FalconJX][FlexJS] COMPJSC and Build order)
>>>> > >
>>>> > > Fred Thomas did some work in this area about a year ago. In the
>>>> > > flex-oem-compiler module that FB (and maybe other IDEs) use to
>>>>talk
>>>>to
>>>> > the
>>>> > > compiler, he added a FLEXJS_DUAL -js-output-type. Not sure how
>>>>well it
>>>> > > works.
>>>> > >
>>>> > > Thinking about this some more we'd have to have the same
>>>>configuration
>>>> > > options available to both compilers which might be a bit strange.
>>>>Or
>>>> > > maybe we can convince the compilers to not complain about unknown
>>>> config
>>>> > > parameters.
>>>> > >
>>>> > > We'd have to decide on how to reset the library-path for each
>>>>compile.
>>>> > > The JS compile might use different SWCs than the SWF compile.
>>>> > >
>>>> > > We'd have to select a few conditional compile options that would
>>>>be
>>>> > > different for each compiler. For example, COMPILE::SWF would be
>>>>true
>>>> for
>>>> > > SWF compiling and false for JS compiling and vice versa, and maybe
>>>> > finding
>>>> > > those params on the command-line would have no effect since they
>>>>would
>>>> be
>>>> > > dictated by the compiler.
>>>> > >
>>>> > > Thoughts?
>>>> > > -Alex
>>>> > >
>>>> > > On 10/2/16, 1:45 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>>> > >
>>>> > > >That would be ideal!
>>>> > > >
>>>> > > >- Josh
>>>> > > >
>>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui" <aha...@adobe.com> wrote:
>>>> > > >
>>>> > > >> One more thought on this: now that COMPJSC can more or less
>>>>build
>>>> its
>>>> > > >>own
>>>> > > >> output instead of relying on COMPC to package its pile of .js
>>>>files,
>>>> > it
>>>> > > >> might be worth experimenting with combining Falcon and FalconJX
>>>>so
>>>> > COMPC
>>>> > > >> can produce a SWC or a SWC with JS files based on some
>>>>configuration
>>>> > > >> parameter. Then there would only be one compiler that produces
>>>>SWFs
>>>> > or
>>>> > > >>JS
>>>> > > >> based on some -output-type flag.
>>>> > > >>
>>>> > > >> Thoughts?
>>>> > > >> -Alex
>>>> > > >>
>>>> > > >> On 10/1/16, 10:18 PM, "Alex Harui" <aha...@adobe.com> wrote:
>>>> > > >>
>>>> > > >> >Hi Chris,
>>>> > > >> >
>>>> > > >> >When I read this, I realized I already pushed the changes when
>>>>I
>>>> > pushed
>>>> > > >> >some other changes yesterday. If the Maven build didn't blow
>>>>up,
>>>> it
>>>> > is
>>>> > > >> >probably because it is using its own compile-xx-config.xml
>>>>files so
>>>> > is
>>>> > > >> >still generating a pile of .js files and packaging them up on
>>>>the
>>>> SWF
>>>> > > >> >COMPC run.
>>>> > > >> >
>>>> > > >> >-Alex
>>>> > > >> >
>>>> > > >> >On 10/1/16, 6:10 AM, "Christofer Dutz"
>>>><christofer.d...@c-ware.de>
>>>> > > >>wrote:
>>>> > > >> >
>>>> > > >> >>Hi Alex,
>>>> > > >> >>
>>>> > > >> >>
>>>> > > >> >>so I guess ideally this change should be done on a feature
>>>>branch,
>>>> > so
>>>> > > >>I
>>>> > > >> >>can sort out the Maven issues and we'll merge that back as
>>>>soon as
>>>> > > >>all is
>>>> > > >> >>working. I would like to ask you to create a
>>>> > > >>"feature-autobuild/"-branch
>>>> > > >> >>for that. Just give me a short note what branch the stuff is
>>>>in
>>>> and
>>>> > > >>I'll
>>>> > > >> >>try to sort out the Maven issues.
>>>> > > >> >>
>>>> > > >> >>
>>>> > > >> >>Chris
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> > >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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.
>>>>
>>
>
