You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2016/12/02 18:13:43 UTC
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
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" <ah...@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" <ch...@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 <ah...@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" <jo...@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.rovira@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
>>>><ch...@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 <jo...@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.dutz@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 <ah...@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" <jo...@gmail.com> wrote:
>>>> > >
>>>> > > >That would be ideal!
>>>> > > >
>>>> > > >- Josh
>>>> > > >
>>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui" <ah...@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" <ah...@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"
>>>><ch...@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.
>>>>
>>
>
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Carlos,
In that case they belong into separate modules. Besides this being work, what other reason would there be to keep them in the same module?
Producing two primary artifacts for one module is actually not discussable if we want to keep Maven support working cleanly without hacks.
Chris
Am 01.02.17, 12:14 schrieb "carlos.rovira@gmail.com im Auftrag von Carlos Rovira" <carlos.rovira@gmail.com im Auftrag von carlos.rovira@codeoscopic.com>:
Hi Chris
2017-02-01 11:34 GMT+01:00 Christofer Dutz <ch...@c-ware.de>:
> Hi guys,
>
> I’d love to see basic go away. I already excluded it from the maven
> distribution to avoid problems in IntelliJ.
>
>
But, if my proposal of separating flexjs components from basic html tags
are ok, we'll end with two. Right now is clear that doesn't has sense since
both are essentially the same. But think that people using "imported
component sets" (non original to FlexJS) like MDL (CreateJS, Bootstrap, or
whatever), will need those tags that are HTML and not other components ->
mdl:Button instead of js:Button, mdl layouts instead of js:Container, and
so on....
SO for me we should have: Basic (with only those tags) and then HTML, MDL,
Express, and others at the same level. So people could use this ones in
isolation or combined if they one.
This would require me to make some refactors in MDL to remove any
dependency. Some of the MDL components (but very few right now) are behind
this philosophy (i.e: Slider or RadioButton).
For example UIBase or UIButtonBase should be part of Basic, but Button or
Container should be part of HTML. In this way MDL components will extend
UIBase but never depends on js:Button or js:Container....
> Didn’t see that “question 3” … what would these two swcs be? I am asking
> because Maven has the concept of one primary artifact per module. We are
> currently producing one main artifact and an additional artifact using a
> classifier, but what are you talking about in this case?
>
I think Alex says: "instead of merging all SWF and JS classes in one SWc
that rule them all, let's separate for platforms". For me it makes sense,
since if you compile for HTML you don't need any swf classes right? so you
end removing weight that make swc fat for nothing
>
> I also don’t know what “AUTO” is …
>
> Chris
>
>
>
> Am 01.02.17, 11:22 schrieb "carlos.rovira@gmail.com im Auftrag von Carlos
> Rovira" <carlos.rovira@gmail.com im Auftrag von carlosrovira@apache.org>:
>
> HI Alex,
>
>
> 2017-01-31 18:41 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
> > OK, I have something working. It is in the "dual" branch I just
> pushed.
> >
>
> great :)
>
>
> > But there is a catch: MXMLJSC requires Java 7 or greater and Flash
> > Builder is packaged with Java 6. So, in order to use this
> capability from
> > FB, you will need to upgrade FB to use Java 7 as in this post [1].
> So
> > that's the first question: Would we want to require folks to
> upgrade FB
> > to Java 7? I don't think we can script the upgrade to automate it
> for
> > people as there are permissions issues in the process. But
> currently, I
> > think it is worth it, since that means you don't have to use separate
> > launch scripts to run the JS compile, although I think it is
> possible to
> > have a way to fall back to the current mechanism of SWF-only
> compilation
> > and use the separate launch script if folks can't upgrade.
> >
> >
> IMHO, for FlexJS that is new tech we should not be looking at FB
> anymore.
> I understand it for old Flex SDK, legacy SDK goes with legacy IDE....is
> right for me
> But considering FlexJS, please we should concentrate on newer options
> begin
> developed
> with FlexJS...
>
>
> So that's question #2: Can I start replacing HTML with Basic?
> >
> >
> I think yes, and I want to suggest something here. I created some basic
> HTML tags (span, a, div, h1,...)
> I think we should separate that tags for normal SDK components like
> js:Container, js:Button...
> those tags are the most basic structures, and FlexJS component is
> somewhat
> the immediate next level.
> In cases like MDL, I could depend it only from basic tags and not from
> FlexJS component.
> Both avoiding actual confusion of user trying to use both a the time
> and
> better structuring and removing things
> People will Neve use (or should never use). And if they want it...PAYG
> and
> introduce it in your build and your code.
>
> Makes that sense?
>
>
> > question #3: Any objections to moving from one SWC per library to
> two?
> >
> >
> It seems ok to me at all. And this should remove weight as well
> removing
> dependencies that are not used never in the end
>
>
> > Any objections to supporting "AUTO" as a special value?
> >
> >
> Here can't help since don't know exactly what's what Fred did
>
>
> Thanks!
>
> Carlos
>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
--
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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Carlos Rovira <ca...@apache.org>.
2017-02-02 17:38 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> I have not worked with ANEs, but AIUI, there is one API definition and
> multiple platform object codes. For FlexJS SWCs there are different API
> definitions per platform.
Diferent APIs? mmm I thought that our objective was to have one API that
encapsulate
JS and SWF (and in the future other platforms if we want). So only 1 API.
FlexJS Express or other components implements JS and SWF. MDL only JS for
the moment
(but maybe one day we could have SWF). If I use this SWCs in my App I will
only have one code
using the same API and I'll get one or two outputs. Right?
--
Carlos Rovira
http://about.me/carlosrovira
AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
I was going to suggest something down the path of: creating the primary artifact which contains library.swf and library-is.swf. We could use these in Ant, Maven and newer IDEs and additionally continue to produce a separate js-swc (as we are doing now) which only legacy IDEs need to use. The additional library-js.swf shouldn't confuse the old IDEs, am I correct?
Would that be a compromise?
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: Alex Harui <ah...@adobe.com>
Datum: 02.02.17 19:36 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
I'm going to try to respond to both you and Carlos.
IMO, there are "Application Developers" (AppDevs) and "Component/Framework
Developers" (CompDevs). Today, in FlexJS, an AppDev can write MXML and AS
and use certain APIs and his/her code will run compile into a SWF or a
pile of JS.
But some CompDev probably needs to write SWF-specific code and/or
JS-specific code. We have biased the framework to allow CompDevs to go
low-level. We could have made a different design decision and said to
CompDevs: "you must only use these APIs that we've wrapped around
platform-specific APIs". But, IMO, that will not result in
high-performance applications and is a real pain for us to support. For
every one of you who wrote a Flex app and used a flash.*.* class, you
hopefully understand why. Flex tried to put a layer over Flash so folks
wouldn't have to know flash.*.* APIs, but most of you went low-level
anyway because it was faster or smaller or both. Or Flex hadn't gotten
around to wrapping some Flash API. IMO, we are not set up as a community
of volunteers to try to fight that battle.
So, my philosophy is to let CompDevs go low-level in each of their
libraries and as such, there will be platform-specific code in each
library. But we only have one package (a SWC) for delivering libraries to
AppDevs and CompDevs.
We could make separate SWCs for AppDevs vs CompDevs. Right now we are
creating a "SWC for SWF" and a "SWC for JS" so we are biased towards
CompDevs. The AppDevs see lots of non-common APIs in IDE code completion.
This "dual" compiler change is one solution for AppDevs. It makes it
easier to compile your app against both platforms and see which APIs you
used that don't exist on one of the target platforms. That's because we
control the compiler code.
I'm sure we can annotate our classes so IDEs could be smarter about what
code completions to offer, but that requires getting FB, FlashBuilder,
IntelliJ, FlashDevelop, FDT, Moonshine, and VSCode to change. Only the
last two have active development, so hopefully they will be able to
provide a customer benefit by being smarter.
But even then, I think AppDevs will want to cheat and write
platform-specific code on occasion.
So I keep coming back to the answer that "SWC for SWF" and a "SWC for JS"
per library is the right packaging, but I'm definitely open to other ideas
that we can practically do without abandoning the legacy IDEs.
We can make the compiler smarter. We can package extra files in SWCs but
the IDEs only expect a single library.swf right now. We can tweak our
Maven mojos. We can do more work and deploy "Universal SWCs" (a single
SWC with a library.swf and a js-library.swf) for Maven and VSCode and
Moonshine but deliver "SWCs for JS" for legacy IDEs. I won't claim to
have the right answer, I just know we have one reasonably good answer now.
But also remember that any work done in this area has to be traded off
against other work so consider how important improvements here are vs
other things on the to-do list.
Thoughts?
-Alex
On 2/2/17, 9:32 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Alex,
>
>all I’m currently concerned about is that it will be painfull for our
>users. And for us, because as soon as no-brain-developers will start
>using FlexJS, we will probably be swamped with support requests. And I
>remember myself being quite confused about it even now … so I usually try
>to build and if there’s errors I’ll add the second option an try again.
>
>I would definitely not enjoy having to deal with three SWCs per library.
>Ideally we would have only one (That would actually make me
>super-duper-ultra-happy). It would ease up explaining things, it would
>make the Maven plugin a lot simpler and I guess it would reduce
>frustration with early adopters.
>
>If there’s anything I can do to make this happen, just tell me what to do.
>
>Chris
>
>
>
>Am 02.02.17, 17:38 schrieb "Alex Harui" <ah...@adobe.com>:
>
> There are already two lib folders (actually three). Today we have:
>
> Frameworks/libs: XXX.SWC contains:
> -Flash-based Class Definitions
> -JS files for JS compiles
> Frameworks/js/FlexJS/libs: XXXJS.SWC contains:
> -JS.swc-based Class Definitions
> Js/libs: SWC contains
> -JS.swc-based Class Definitinons from flex-typedefs
> -JS files for externs
>
> Before I consider this "dual" thing done, I was going to change
>things so
> there is a copy of the JS files in the XXXJS.swc. AIUI, Maven has two
> categories of SWCs: externs and regular, so you can see by packing JS
> files in the XXXJS.swc it will have the same sort of contents.
>
> I have not worked with ANEs, but AIUI, there is one API definition and
> multiple platform object codes. For FlexJS SWCs there are different
>API
> definitions per platform. IMO, by packing JS files in the SWC we are
> doing something like what ANE packaging does. The JS is effectively
>the
> platform object code. But all existing IDEs expect only a single
> library.swf for the API definitions. We can change that, but then
>every
> IDE would have to change. IMO, backward-compatibility is still
>important,
> not just for FB. We could still have two SWCs per library and still
> package a js-library.swf into the SWF SWC if that makes VSCode work
> better. We could also make the compiler guess that if there is a
>XXX.SWC
> to first look for a XXXJS.SWC in another folder. That would be far
> simpler, IMO.
>
> Could we create a third SWC with only the definitions in common?
> Probably, but IMO, not critical right now (or at least, that's not
>what I
> want to do with my time). The dual compile will effectively show you
> what is common, and I hope we can add documentation to mark what is
>common.
>
> I think there are two pieces here:
> -Will it be to painful to require third parties to ship two SWCs per
> library?
> -Can we make it so that if you specify XXX.SWC on the library path,
>you
> don't also have to specify XXXJS.SWC in the config?
>
> I think we can make the compilers make some assumptions so that if
>there
> are two SWCs per library the consumer only has to think about one.
>But
> for backward compatibility, I'd say we still need two SWCs per
>library.
>
> Thoughts?
> -Alex
>
>
>
> On 2/2/17, 3:10 AM, "carlos.rovira@gmail.com on behalf of Carlos
>Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>wrote:
>
> >I think self contain is better too. For example Adobe AIR does the
>same
> >with Multiplatform ANEs. If the ANE is implemented for iOS, Android,
>and
> >more,...all goes in the same .ane and I think that's really good,
>since
> >the
> >library is in fact Multiplatform and ready to use for anyone in
>anyplace
> >:)
> >
> >2017-02-02 10:46 GMT+01:00 Christofer Dutz
><ch...@c-ware.de>:
> >
> >> Would it be somehow possible to make the swcs self-contained?
> >> Right now they contain catalog.xml and library.swf … couldn’t this
> >>contain
> >> something like a “catalog-js.xml” and a “library-js.swf” … this
>way we
> >> could just add a dependency to a SWC and the compiler could
>internally
> >>grab
> >> what he needs. This would the the option which I would prefer most
>…
> >>sort
> >> of 1000000000+ ;-)
> >>
> >> Chris
> >>
> >> Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
> >>
> >> So there would be two different lib folders? One for swf
>compilation
> >> and another for js compilation? Maybe a third lib folder for “dual”
> >> compilation?
> >>
> >> Here’s a thought: Would it be possible to create a “dual” swc
>which
> >> would contain the definitions for both JS and SWF? And have falcon
> >> understand how to read the correct one depending on the output?
> >>
> >> > On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com>
>wrote:
> >> >
> >> >
> >> >
> >> > On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
> >> >
> >> >> One question: How do you envision swc for third party
>libraries
> >>if
> >> both
> >> >> JS and SWF swcs are being used?
> >> >>
> >> >> Is this strictly an SDK thing or would there be some
>mechanism
> >>for
> >> having
> >> >> split swcs for libs as well?
> >> >
> >> > I think third-parties will also have to distribute two SWCs
>if
> >>there
> >> are
> >> > differences in the API surfaces. If you have a high-level
>library
> >> that
> >> > just talks to downstream libraries and has no COMPILE::
>blocks you
> >> > probably only need the one SWC.
> >> >
> >> > Is this an ok thing to do to our customers?
> >> >
> >> > -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
I'm going to try to respond to both you and Carlos.
IMO, there are "Application Developers" (AppDevs) and "Component/Framework
Developers" (CompDevs). Today, in FlexJS, an AppDev can write MXML and AS
and use certain APIs and his/her code will run compile into a SWF or a
pile of JS.
But some CompDev probably needs to write SWF-specific code and/or
JS-specific code. We have biased the framework to allow CompDevs to go
low-level. We could have made a different design decision and said to
CompDevs: "you must only use these APIs that we've wrapped around
platform-specific APIs". But, IMO, that will not result in
high-performance applications and is a real pain for us to support. For
every one of you who wrote a Flex app and used a flash.*.* class, you
hopefully understand why. Flex tried to put a layer over Flash so folks
wouldn't have to know flash.*.* APIs, but most of you went low-level
anyway because it was faster or smaller or both. Or Flex hadn't gotten
around to wrapping some Flash API. IMO, we are not set up as a community
of volunteers to try to fight that battle.
So, my philosophy is to let CompDevs go low-level in each of their
libraries and as such, there will be platform-specific code in each
library. But we only have one package (a SWC) for delivering libraries to
AppDevs and CompDevs.
We could make separate SWCs for AppDevs vs CompDevs. Right now we are
creating a "SWC for SWF" and a "SWC for JS" so we are biased towards
CompDevs. The AppDevs see lots of non-common APIs in IDE code completion.
This "dual" compiler change is one solution for AppDevs. It makes it
easier to compile your app against both platforms and see which APIs you
used that don't exist on one of the target platforms. That's because we
control the compiler code.
I'm sure we can annotate our classes so IDEs could be smarter about what
code completions to offer, but that requires getting FB, FlashBuilder,
IntelliJ, FlashDevelop, FDT, Moonshine, and VSCode to change. Only the
last two have active development, so hopefully they will be able to
provide a customer benefit by being smarter.
But even then, I think AppDevs will want to cheat and write
platform-specific code on occasion.
So I keep coming back to the answer that "SWC for SWF" and a "SWC for JS"
per library is the right packaging, but I'm definitely open to other ideas
that we can practically do without abandoning the legacy IDEs.
We can make the compiler smarter. We can package extra files in SWCs but
the IDEs only expect a single library.swf right now. We can tweak our
Maven mojos. We can do more work and deploy "Universal SWCs" (a single
SWC with a library.swf and a js-library.swf) for Maven and VSCode and
Moonshine but deliver "SWCs for JS" for legacy IDEs. I won't claim to
have the right answer, I just know we have one reasonably good answer now.
But also remember that any work done in this area has to be traded off
against other work so consider how important improvements here are vs
other things on the to-do list.
Thoughts?
-Alex
On 2/2/17, 9:32 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Alex,
>
>all I’m currently concerned about is that it will be painfull for our
>users. And for us, because as soon as no-brain-developers will start
>using FlexJS, we will probably be swamped with support requests. And I
>remember myself being quite confused about it even now … so I usually try
>to build and if there’s errors I’ll add the second option an try again.
>
>I would definitely not enjoy having to deal with three SWCs per library.
>Ideally we would have only one (That would actually make me
>super-duper-ultra-happy). It would ease up explaining things, it would
>make the Maven plugin a lot simpler and I guess it would reduce
>frustration with early adopters.
>
>If there’s anything I can do to make this happen, just tell me what to do.
>
>Chris
>
>
>
>Am 02.02.17, 17:38 schrieb "Alex Harui" <ah...@adobe.com>:
>
> There are already two lib folders (actually three). Today we have:
>
> Frameworks/libs: XXX.SWC contains:
> -Flash-based Class Definitions
> -JS files for JS compiles
> Frameworks/js/FlexJS/libs: XXXJS.SWC contains:
> -JS.swc-based Class Definitions
> Js/libs: SWC contains
> -JS.swc-based Class Definitinons from flex-typedefs
> -JS files for externs
>
> Before I consider this "dual" thing done, I was going to change
>things so
> there is a copy of the JS files in the XXXJS.swc. AIUI, Maven has two
> categories of SWCs: externs and regular, so you can see by packing JS
> files in the XXXJS.swc it will have the same sort of contents.
>
> I have not worked with ANEs, but AIUI, there is one API definition and
> multiple platform object codes. For FlexJS SWCs there are different
>API
> definitions per platform. IMO, by packing JS files in the SWC we are
> doing something like what ANE packaging does. The JS is effectively
>the
> platform object code. But all existing IDEs expect only a single
> library.swf for the API definitions. We can change that, but then
>every
> IDE would have to change. IMO, backward-compatibility is still
>important,
> not just for FB. We could still have two SWCs per library and still
> package a js-library.swf into the SWF SWC if that makes VSCode work
> better. We could also make the compiler guess that if there is a
>XXX.SWC
> to first look for a XXXJS.SWC in another folder. That would be far
> simpler, IMO.
>
> Could we create a third SWC with only the definitions in common?
> Probably, but IMO, not critical right now (or at least, that's not
>what I
> want to do with my time). The dual compile will effectively show you
> what is common, and I hope we can add documentation to mark what is
>common.
>
> I think there are two pieces here:
> -Will it be to painful to require third parties to ship two SWCs per
> library?
> -Can we make it so that if you specify XXX.SWC on the library path,
>you
> don't also have to specify XXXJS.SWC in the config?
>
> I think we can make the compilers make some assumptions so that if
>there
> are two SWCs per library the consumer only has to think about one.
>But
> for backward compatibility, I'd say we still need two SWCs per
>library.
>
> Thoughts?
> -Alex
>
>
>
> On 2/2/17, 3:10 AM, "carlos.rovira@gmail.com on behalf of Carlos
>Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>wrote:
>
> >I think self contain is better too. For example Adobe AIR does the
>same
> >with Multiplatform ANEs. If the ANE is implemented for iOS, Android,
>and
> >more,...all goes in the same .ane and I think that's really good,
>since
> >the
> >library is in fact Multiplatform and ready to use for anyone in
>anyplace
> >:)
> >
> >2017-02-02 10:46 GMT+01:00 Christofer Dutz
><ch...@c-ware.de>:
> >
> >> Would it be somehow possible to make the swcs self-contained?
> >> Right now they contain catalog.xml and library.swf … couldn’t this
> >>contain
> >> something like a “catalog-js.xml” and a “library-js.swf” … this
>way we
> >> could just add a dependency to a SWC and the compiler could
>internally
> >>grab
> >> what he needs. This would the the option which I would prefer most
>…
> >>sort
> >> of 1000000000+ ;-)
> >>
> >> Chris
> >>
> >> Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
> >>
> >> So there would be two different lib folders? One for swf
>compilation
> >> and another for js compilation? Maybe a third lib folder for “dual”
> >> compilation?
> >>
> >> Here’s a thought: Would it be possible to create a “dual” swc
>which
> >> would contain the definitions for both JS and SWF? And have falcon
> >> understand how to read the correct one depending on the output?
> >>
> >> > On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com>
>wrote:
> >> >
> >> >
> >> >
> >> > On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
> >> >
> >> >> One question: How do you envision swc for third party
>libraries
> >>if
> >> both
> >> >> JS and SWF swcs are being used?
> >> >>
> >> >> Is this strictly an SDK thing or would there be some
>mechanism
> >>for
> >> having
> >> >> split swcs for libs as well?
> >> >
> >> > I think third-parties will also have to distribute two SWCs
>if
> >>there
> >> are
> >> > differences in the API surfaces. If you have a high-level
>library
> >> that
> >> > just talks to downstream libraries and has no COMPILE::
>blocks you
> >> > probably only need the one SWC.
> >> >
> >> > Is this an ok thing to do to our customers?
> >> >
> >> > -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
all I’m currently concerned about is that it will be painfull for our users. And for us, because as soon as no-brain-developers will start using FlexJS, we will probably be swamped with support requests. And I remember myself being quite confused about it even now … so I usually try to build and if there’s errors I’ll add the second option an try again.
I would definitely not enjoy having to deal with three SWCs per library. Ideally we would have only one (That would actually make me super-duper-ultra-happy). It would ease up explaining things, it would make the Maven plugin a lot simpler and I guess it would reduce frustration with early adopters.
If there’s anything I can do to make this happen, just tell me what to do.
Chris
Am 02.02.17, 17:38 schrieb "Alex Harui" <ah...@adobe.com>:
There are already two lib folders (actually three). Today we have:
Frameworks/libs: XXX.SWC contains:
-Flash-based Class Definitions
-JS files for JS compiles
Frameworks/js/FlexJS/libs: XXXJS.SWC contains:
-JS.swc-based Class Definitions
Js/libs: SWC contains
-JS.swc-based Class Definitinons from flex-typedefs
-JS files for externs
Before I consider this "dual" thing done, I was going to change things so
there is a copy of the JS files in the XXXJS.swc. AIUI, Maven has two
categories of SWCs: externs and regular, so you can see by packing JS
files in the XXXJS.swc it will have the same sort of contents.
I have not worked with ANEs, but AIUI, there is one API definition and
multiple platform object codes. For FlexJS SWCs there are different API
definitions per platform. IMO, by packing JS files in the SWC we are
doing something like what ANE packaging does. The JS is effectively the
platform object code. But all existing IDEs expect only a single
library.swf for the API definitions. We can change that, but then every
IDE would have to change. IMO, backward-compatibility is still important,
not just for FB. We could still have two SWCs per library and still
package a js-library.swf into the SWF SWC if that makes VSCode work
better. We could also make the compiler guess that if there is a XXX.SWC
to first look for a XXXJS.SWC in another folder. That would be far
simpler, IMO.
Could we create a third SWC with only the definitions in common?
Probably, but IMO, not critical right now (or at least, that's not what I
want to do with my time). The dual compile will effectively show you
what is common, and I hope we can add documentation to mark what is common.
I think there are two pieces here:
-Will it be to painful to require third parties to ship two SWCs per
library?
-Can we make it so that if you specify XXX.SWC on the library path, you
don't also have to specify XXXJS.SWC in the config?
I think we can make the compilers make some assumptions so that if there
are two SWCs per library the consumer only has to think about one. But
for backward compatibility, I'd say we still need two SWCs per library.
Thoughts?
-Alex
On 2/2/17, 3:10 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>I think self contain is better too. For example Adobe AIR does the same
>with Multiplatform ANEs. If the ANE is implemented for iOS, Android, and
>more,...all goes in the same .ane and I think that's really good, since
>the
>library is in fact Multiplatform and ready to use for anyone in anyplace
>:)
>
>2017-02-02 10:46 GMT+01:00 Christofer Dutz <ch...@c-ware.de>:
>
>> Would it be somehow possible to make the swcs self-contained?
>> Right now they contain catalog.xml and library.swf … couldn’t this
>>contain
>> something like a “catalog-js.xml” and a “library-js.swf” … this way we
>> could just add a dependency to a SWC and the compiler could internally
>>grab
>> what he needs. This would the the option which I would prefer most …
>>sort
>> of 1000000000+ ;-)
>>
>> Chris
>>
>> Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
>>
>> So there would be two different lib folders? One for swf compilation
>> and another for js compilation? Maybe a third lib folder for “dual”
>> compilation?
>>
>> Here’s a thought: Would it be possible to create a “dual” swc which
>> would contain the definitions for both JS and SWF? And have falcon
>> understand how to read the correct one depending on the output?
>>
>> > On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >
>> >
>> > On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>> >
>> >> One question: How do you envision swc for third party libraries
>>if
>> both
>> >> JS and SWF swcs are being used?
>> >>
>> >> Is this strictly an SDK thing or would there be some mechanism
>>for
>> having
>> >> split swcs for libs as well?
>> >
>> > I think third-parties will also have to distribute two SWCs if
>>there
>> are
>> > differences in the API surfaces. If you have a high-level library
>> that
>> > just talks to downstream libraries and has no COMPILE:: blocks you
>> > probably only need the one SWC.
>> >
>> > Is this an ok thing to do to our customers?
>> >
>> > -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
There are already two lib folders (actually three). Today we have:
Frameworks/libs: XXX.SWC contains:
-Flash-based Class Definitions
-JS files for JS compiles
Frameworks/js/FlexJS/libs: XXXJS.SWC contains:
-JS.swc-based Class Definitions
Js/libs: SWC contains
-JS.swc-based Class Definitinons from flex-typedefs
-JS files for externs
Before I consider this "dual" thing done, I was going to change things so
there is a copy of the JS files in the XXXJS.swc. AIUI, Maven has two
categories of SWCs: externs and regular, so you can see by packing JS
files in the XXXJS.swc it will have the same sort of contents.
I have not worked with ANEs, but AIUI, there is one API definition and
multiple platform object codes. For FlexJS SWCs there are different API
definitions per platform. IMO, by packing JS files in the SWC we are
doing something like what ANE packaging does. The JS is effectively the
platform object code. But all existing IDEs expect only a single
library.swf for the API definitions. We can change that, but then every
IDE would have to change. IMO, backward-compatibility is still important,
not just for FB. We could still have two SWCs per library and still
package a js-library.swf into the SWF SWC if that makes VSCode work
better. We could also make the compiler guess that if there is a XXX.SWC
to first look for a XXXJS.SWC in another folder. That would be far
simpler, IMO.
Could we create a third SWC with only the definitions in common?
Probably, but IMO, not critical right now (or at least, that's not what I
want to do with my time). The dual compile will effectively show you
what is common, and I hope we can add documentation to mark what is common.
I think there are two pieces here:
-Will it be to painful to require third parties to ship two SWCs per
library?
-Can we make it so that if you specify XXX.SWC on the library path, you
don't also have to specify XXXJS.SWC in the config?
I think we can make the compilers make some assumptions so that if there
are two SWCs per library the consumer only has to think about one. But
for backward compatibility, I'd say we still need two SWCs per library.
Thoughts?
-Alex
On 2/2/17, 3:10 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>I think self contain is better too. For example Adobe AIR does the same
>with Multiplatform ANEs. If the ANE is implemented for iOS, Android, and
>more,...all goes in the same .ane and I think that's really good, since
>the
>library is in fact Multiplatform and ready to use for anyone in anyplace
>:)
>
>2017-02-02 10:46 GMT+01:00 Christofer Dutz <ch...@c-ware.de>:
>
>> Would it be somehow possible to make the swcs self-contained?
>> Right now they contain catalog.xml and library.swf … couldn’t this
>>contain
>> something like a “catalog-js.xml” and a “library-js.swf” … this way we
>> could just add a dependency to a SWC and the compiler could internally
>>grab
>> what he needs. This would the the option which I would prefer most …
>>sort
>> of 1000000000+ ;-)
>>
>> Chris
>>
>> Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
>>
>> So there would be two different lib folders? One for swf compilation
>> and another for js compilation? Maybe a third lib folder for “dual”
>> compilation?
>>
>> Here’s a thought: Would it be possible to create a “dual” swc which
>> would contain the definitions for both JS and SWF? And have falcon
>> understand how to read the correct one depending on the output?
>>
>> > On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >
>> >
>> > On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>> >
>> >> One question: How do you envision swc for third party libraries
>>if
>> both
>> >> JS and SWF swcs are being used?
>> >>
>> >> Is this strictly an SDK thing or would there be some mechanism
>>for
>> having
>> >> split swcs for libs as well?
>> >
>> > I think third-parties will also have to distribute two SWCs if
>>there
>> are
>> > differences in the API surfaces. If you have a high-level library
>> that
>> > just talks to downstream libraries and has no COMPILE:: blocks you
>> > probably only need the one SWC.
>> >
>> > Is this an ok thing to do to our customers?
>> >
>> > -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I think self contain is better too. For example Adobe AIR does the same
with Multiplatform ANEs. If the ANE is implemented for iOS, Android, and
more,...all goes in the same .ane and I think that's really good, since the
library is in fact Multiplatform and ready to use for anyone in anyplace :)
2017-02-02 10:46 GMT+01:00 Christofer Dutz <ch...@c-ware.de>:
> Would it be somehow possible to make the swcs self-contained?
> Right now they contain catalog.xml and library.swf … couldn’t this contain
> something like a “catalog-js.xml” and a “library-js.swf” … this way we
> could just add a dependency to a SWC and the compiler could internally grab
> what he needs. This would the the option which I would prefer most … sort
> of 1000000000+ ;-)
>
> Chris
>
> Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
>
> So there would be two different lib folders? One for swf compilation
> and another for js compilation? Maybe a third lib folder for “dual”
> compilation?
>
> Here’s a thought: Would it be possible to create a “dual” swc which
> would contain the definitions for both JS and SWF? And have falcon
> understand how to read the correct one depending on the output?
>
> > On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >
> >
> > On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> One question: How do you envision swc for third party libraries if
> both
> >> JS and SWF swcs are being used?
> >>
> >> Is this strictly an SDK thing or would there be some mechanism for
> having
> >> split swcs for libs as well?
> >
> > I think third-parties will also have to distribute two SWCs if there
> are
> > differences in the API surfaces. If you have a high-level library
> that
> > just talks to downstream libraries and has no COMPILE:: blocks you
> > probably only need the one SWC.
> >
> > Is this an ok thing to do to our customers?
> >
> > -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Would it be somehow possible to make the swcs self-contained?
Right now they contain catalog.xml and library.swf … couldn’t this contain something like a “catalog-js.xml” and a “library-js.swf” … this way we could just add a dependency to a SWC and the compiler could internally grab what he needs. This would the the option which I would prefer most … sort of 1000000000+ ;-)
Chris
Am 02.02.17, 10:27 schrieb "Harbs" <ha...@gmail.com>:
So there would be two different lib folders? One for swf compilation and another for js compilation? Maybe a third lib folder for “dual” compilation?
Here’s a thought: Would it be possible to create a “dual” swc which would contain the definitions for both JS and SWF? And have falcon understand how to read the correct one depending on the output?
> On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> One question: How do you envision swc for third party libraries if both
>> JS and SWF swcs are being used?
>>
>> Is this strictly an SDK thing or would there be some mechanism for having
>> split swcs for libs as well?
>
> I think third-parties will also have to distribute two SWCs if there are
> differences in the API surfaces. If you have a high-level library that
> just talks to downstream libraries and has no COMPILE:: blocks you
> probably only need the one SWC.
>
> Is this an ok thing to do to our customers?
>
> -Alex
>
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Posted by Harbs <ha...@gmail.com>.
So there would be two different lib folders? One for swf compilation and another for js compilation? Maybe a third lib folder for “dual” compilation?
Here’s a thought: Would it be possible to create a “dual” swc which would contain the definitions for both JS and SWF? And have falcon understand how to read the correct one depending on the output?
> On Feb 2, 2017, at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> One question: How do you envision swc for third party libraries if both
>> JS and SWF swcs are being used?
>>
>> Is this strictly an SDK thing or would there be some mechanism for having
>> split swcs for libs as well?
>
> I think third-parties will also have to distribute two SWCs if there are
> differences in the API surfaces. If you have a high-level library that
> just talks to downstream libraries and has no COMPILE:: blocks you
> probably only need the one SWC.
>
> Is this an ok thing to do to our customers?
>
> -Alex
>
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
to figure about time schedules, it seems you have this already working on
your machine and need some latest touches and refienments right?
So in case I'll separate basic clases and tags, I think it would be better
to do after your change right?
Other way could be to introduce the tags in "Core" SWC and then try to
refactor MDL and remove HTML dependency and see if some class from HTML is
needed and if can be refactor to not need that dependency or we need to
move something from HTML to Core.
2017-02-01 23:05 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >One question: How do you envision swc for third party libraries if both
> >JS and SWF swcs are being used?
> >
> >Is this strictly an SDK thing or would there be some mechanism for having
> >split swcs for libs as well?
>
> I think third-parties will also have to distribute two SWCs if there are
> differences in the API surfaces. If you have a high-level library that
> just talks to downstream libraries and has no COMPILE:: blocks you
> probably only need the one SWC.
>
> Is this an ok thing to do to our customers?
>
> -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: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
On 2/1/17, 1:41 PM, "Harbs" <ha...@gmail.com> wrote:
>One question: How do you envision swc for third party libraries if both
>JS and SWF swcs are being used?
>
>Is this strictly an SDK thing or would there be some mechanism for having
>split swcs for libs as well?
I think third-parties will also have to distribute two SWCs if there are
differences in the API surfaces. If you have a high-level library that
just talks to downstream libraries and has no COMPILE:: blocks you
probably only need the one SWC.
Is this an ok thing to do to our customers?
-Alex
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Posted by Harbs <ha...@gmail.com>.
One question: How do you envision swc for third party libraries if both JS and SWF swcs are being used?
Is this strictly an SDK thing or would there be some mechanism for having split swcs for libs as well?
Harbs
> On Feb 1, 2017, at 6:22 PM, Alex Harui <ah...@adobe.com> wrote:
>
> We are already producing two SWCs per library. For Core, there is
> Core.swc and CoreJS.swc. I think in Maven we call CoreJS an externs SWC.
> Right now you can build your application by just referencing Core.swc,
> since it contains the .JS files, but it contains Class definitions that
> are based on Flash APIs. It just happens to work for JS as long as you
> only use the APIs in common between Core.swc and CoreJS.swc.
>
> IMO, it is more legitimate to start using CoreJS.swc for JS output. That
> way, application developers could use COMPILE::JS and COMPILE::SWF and the
> right platform APIs to work around issues that might arise. And the
> primary reason is so, when migrating, it is easier to tell what old code
> is still depending on Flash APIs without us having to wrap every Sprite
> and rewrite the event model.
>
> That's why, IMO, we want this to be in 0.8.0. I believe we can make
> everything backward compatible so the Maven usage doesn't change if we
> don't have time to tweak how Maven uses these SWCs.
>
> And, FWIW, AUTO when used for -define=COMPILE::SWF,AUTO and
> -define=COMPILE::JS,AUTO, would be mapped to COMPILE::SWF,true and
> COMPILE::JS,false in the SWF compiler and the reverse in the JS compiler.
>
> -Alex
>
>
> On 2/1/17, 4:17 AM, "piotrz" <pi...@gmail.com> wrote:
>
>> Hi Guys,
>>
>> If it is possible to do this as Carlos saying without break Maven build I
>> think we should do this, but not in 0.8.0. We have now enough content to
>> release.
>>
>> Piotr
>>
>>
>>
>> -----
>> Apache Flex PMC
>> piotrzarzycki21@gmail.com
>> --
>> View this message in context:
>> http://apache-flex-development.2333347.n4.nabble.com/FALCONJX-Combining-SW
>> F-and-JS-compilers-was-Re-AW-FalconJX-FlexJS-COMPJSC-and-Build-order-tp556
>> 24p58914.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Posted by Harbs <ha...@gmail.com>.
I personally don’t care that much about Flash Builder. I’m moving more and more over to VS Code. AIUI, VS Code picks up the compiler settings, so if there’s both a js and swf library path, I’m thinking that it should work. Josh could give a more definitive answer on that.
Our JS projects don’t actually contain the code, so I’m not sure how that will help.
> On Feb 2, 2017, at 12:01 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 2/1/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> This! I like!
>>
>> Theoretically it should make it possible to get correct code completion
>> in both COMPILE::SWF and COMPILE::JS blocks. That would be a huge help!
>
> Hmm. Not so sure about that. For one FB project, there is only one set
> of SWCs and I don't know that you would specify both Core and CoreJS on
> the library path in the project settings. I think you would have to
> specify -js-library-path=CoreJS.swc in the additional compiler options and
> that wouldn't help code hinting.
>
> But right now we do have two FB projects per library, so if you have both
> projects open and one specifies the CoreJS.swc in theory you will get code
> hinting correctly for that, but I don't know what FB will actually do.
>
> -Alex
>
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
On 2/1/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>This! I like!
>
>Theoretically it should make it possible to get correct code completion
>in both COMPILE::SWF and COMPILE::JS blocks. That would be a huge help!
Hmm. Not so sure about that. For one FB project, there is only one set
of SWCs and I don't know that you would specify both Core and CoreJS on
the library path in the project settings. I think you would have to
specify -js-library-path=CoreJS.swc in the additional compiler options and
that wouldn't help code hinting.
But right now we do have two FB projects per library, so if you have both
projects open and one specifies the CoreJS.swc in theory you will get code
hinting correctly for that, but I don't know what FB will actually do.
-Alex
Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Posted by Harbs <ha...@gmail.com>.
This! I like!
Theoretically it should make it possible to get correct code completion in both COMPILE::SWF and COMPILE::JS blocks. That would be a huge help!
> On Feb 1, 2017, at 6:22 PM, Alex Harui <ah...@adobe.com> wrote:
>
> And, FWIW, AUTO when used for -define=COMPILE::SWF,AUTO and
> -define=COMPILE::JS,AUTO, would be mapped to COMPILE::SWF,true and
> COMPILE::JS,false in the SWF compiler and the reverse in the JS compiler.
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
We are already producing two SWCs per library. For Core, there is
Core.swc and CoreJS.swc. I think in Maven we call CoreJS an externs SWC.
Right now you can build your application by just referencing Core.swc,
since it contains the .JS files, but it contains Class definitions that
are based on Flash APIs. It just happens to work for JS as long as you
only use the APIs in common between Core.swc and CoreJS.swc.
IMO, it is more legitimate to start using CoreJS.swc for JS output. That
way, application developers could use COMPILE::JS and COMPILE::SWF and the
right platform APIs to work around issues that might arise. And the
primary reason is so, when migrating, it is easier to tell what old code
is still depending on Flash APIs without us having to wrap every Sprite
and rewrite the event model.
That's why, IMO, we want this to be in 0.8.0. I believe we can make
everything backward compatible so the Maven usage doesn't change if we
don't have time to tweak how Maven uses these SWCs.
And, FWIW, AUTO when used for -define=COMPILE::SWF,AUTO and
-define=COMPILE::JS,AUTO, would be mapped to COMPILE::SWF,true and
COMPILE::JS,false in the SWF compiler and the reverse in the JS compiler.
-Alex
On 2/1/17, 4:17 AM, "piotrz" <pi...@gmail.com> wrote:
>Hi Guys,
>
>If it is possible to do this as Carlos saying without break Maven build I
>think we should do this, but not in 0.8.0. We have now enough content to
>release.
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FALCONJX-Combining-SW
>F-and-JS-compilers-was-Re-AW-FalconJX-FlexJS-COMPJSC-and-Build-order-tp556
>24p58914.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by piotrz <pi...@gmail.com>.
Hi Guys,
If it is possible to do this as Carlos saying without break Maven build I
think we should do this, but not in 0.8.0. We have now enough content to
release.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FALCONJX-Combining-SWF-and-JS-compilers-was-Re-AW-FalconJX-FlexJS-COMPJSC-and-Build-order-tp55624p58914.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Chris
2017-02-01 11:34 GMT+01:00 Christofer Dutz <ch...@c-ware.de>:
> Hi guys,
>
> I’d love to see basic go away. I already excluded it from the maven
> distribution to avoid problems in IntelliJ.
>
>
But, if my proposal of separating flexjs components from basic html tags
are ok, we'll end with two. Right now is clear that doesn't has sense since
both are essentially the same. But think that people using "imported
component sets" (non original to FlexJS) like MDL (CreateJS, Bootstrap, or
whatever), will need those tags that are HTML and not other components ->
mdl:Button instead of js:Button, mdl layouts instead of js:Container, and
so on....
SO for me we should have: Basic (with only those tags) and then HTML, MDL,
Express, and others at the same level. So people could use this ones in
isolation or combined if they one.
This would require me to make some refactors in MDL to remove any
dependency. Some of the MDL components (but very few right now) are behind
this philosophy (i.e: Slider or RadioButton).
For example UIBase or UIButtonBase should be part of Basic, but Button or
Container should be part of HTML. In this way MDL components will extend
UIBase but never depends on js:Button or js:Container....
> Didn’t see that “question 3” … what would these two swcs be? I am asking
> because Maven has the concept of one primary artifact per module. We are
> currently producing one main artifact and an additional artifact using a
> classifier, but what are you talking about in this case?
>
I think Alex says: "instead of merging all SWF and JS classes in one SWc
that rule them all, let's separate for platforms". For me it makes sense,
since if you compile for HTML you don't need any swf classes right? so you
end removing weight that make swc fat for nothing
>
> I also don’t know what “AUTO” is …
>
> Chris
>
>
>
> Am 01.02.17, 11:22 schrieb "carlos.rovira@gmail.com im Auftrag von Carlos
> Rovira" <carlos.rovira@gmail.com im Auftrag von carlosrovira@apache.org>:
>
> HI Alex,
>
>
> 2017-01-31 18:41 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
> > OK, I have something working. It is in the "dual" branch I just
> pushed.
> >
>
> great :)
>
>
> > But there is a catch: MXMLJSC requires Java 7 or greater and Flash
> > Builder is packaged with Java 6. So, in order to use this
> capability from
> > FB, you will need to upgrade FB to use Java 7 as in this post [1].
> So
> > that's the first question: Would we want to require folks to
> upgrade FB
> > to Java 7? I don't think we can script the upgrade to automate it
> for
> > people as there are permissions issues in the process. But
> currently, I
> > think it is worth it, since that means you don't have to use separate
> > launch scripts to run the JS compile, although I think it is
> possible to
> > have a way to fall back to the current mechanism of SWF-only
> compilation
> > and use the separate launch script if folks can't upgrade.
> >
> >
> IMHO, for FlexJS that is new tech we should not be looking at FB
> anymore.
> I understand it for old Flex SDK, legacy SDK goes with legacy IDE....is
> right for me
> But considering FlexJS, please we should concentrate on newer options
> begin
> developed
> with FlexJS...
>
>
> So that's question #2: Can I start replacing HTML with Basic?
> >
> >
> I think yes, and I want to suggest something here. I created some basic
> HTML tags (span, a, div, h1,...)
> I think we should separate that tags for normal SDK components like
> js:Container, js:Button...
> those tags are the most basic structures, and FlexJS component is
> somewhat
> the immediate next level.
> In cases like MDL, I could depend it only from basic tags and not from
> FlexJS component.
> Both avoiding actual confusion of user trying to use both a the time
> and
> better structuring and removing things
> People will Neve use (or should never use). And if they want it...PAYG
> and
> introduce it in your build and your code.
>
> Makes that sense?
>
>
> > question #3: Any objections to moving from one SWC per library to
> two?
> >
> >
> It seems ok to me at all. And this should remove weight as well
> removing
> dependencies that are not used never in the end
>
>
> > Any objections to supporting "AUTO" as a special value?
> >
> >
> Here can't help since don't know exactly what's what Fred did
>
>
> Thanks!
>
> Carlos
>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
--
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: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi guys,
I’d love to see basic go away. I already excluded it from the maven distribution to avoid problems in IntelliJ.
Didn’t see that “question 3” … what would these two swcs be? I am asking because Maven has the concept of one primary artifact per module. We are currently producing one main artifact and an additional artifact using a classifier, but what are you talking about in this case?
I also don’t know what “AUTO” is …
Chris
Am 01.02.17, 11:22 schrieb "carlos.rovira@gmail.com im Auftrag von Carlos Rovira" <carlos.rovira@gmail.com im Auftrag von carlosrovira@apache.org>:
HI Alex,
2017-01-31 18:41 GMT+01:00 Alex Harui <ah...@adobe.com>:
> OK, I have something working. It is in the "dual" branch I just pushed.
>
great :)
> But there is a catch: MXMLJSC requires Java 7 or greater and Flash
> Builder is packaged with Java 6. So, in order to use this capability from
> FB, you will need to upgrade FB to use Java 7 as in this post [1]. So
> that's the first question: Would we want to require folks to upgrade FB
> to Java 7? I don't think we can script the upgrade to automate it for
> people as there are permissions issues in the process. But currently, I
> think it is worth it, since that means you don't have to use separate
> launch scripts to run the JS compile, although I think it is possible to
> have a way to fall back to the current mechanism of SWF-only compilation
> and use the separate launch script if folks can't upgrade.
>
>
IMHO, for FlexJS that is new tech we should not be looking at FB anymore.
I understand it for old Flex SDK, legacy SDK goes with legacy IDE....is
right for me
But considering FlexJS, please we should concentrate on newer options begin
developed
with FlexJS...
So that's question #2: Can I start replacing HTML with Basic?
>
>
I think yes, and I want to suggest something here. I created some basic
HTML tags (span, a, div, h1,...)
I think we should separate that tags for normal SDK components like
js:Container, js:Button...
those tags are the most basic structures, and FlexJS component is somewhat
the immediate next level.
In cases like MDL, I could depend it only from basic tags and not from
FlexJS component.
Both avoiding actual confusion of user trying to use both a the time and
better structuring and removing things
People will Neve use (or should never use). And if they want it...PAYG and
introduce it in your build and your code.
Makes that sense?
> question #3: Any objections to moving from one SWC per library to two?
>
>
It seems ok to me at all. And this should remove weight as well removing
dependencies that are not used never in the end
> Any objections to supporting "AUTO" as a special value?
>
>
Here can't help since don't know exactly what's what Fred did
Thanks!
Carlos
--
Carlos Rovira
http://about.me/carlosrovira
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Carlos Rovira <ca...@apache.org>.
HI Alex,
2017-01-31 18:41 GMT+01:00 Alex Harui <ah...@adobe.com>:
> OK, I have something working. It is in the "dual" branch I just pushed.
>
great :)
> But there is a catch: MXMLJSC requires Java 7 or greater and Flash
> Builder is packaged with Java 6. So, in order to use this capability from
> FB, you will need to upgrade FB to use Java 7 as in this post [1]. So
> that's the first question: Would we want to require folks to upgrade FB
> to Java 7? I don't think we can script the upgrade to automate it for
> people as there are permissions issues in the process. But currently, I
> think it is worth it, since that means you don't have to use separate
> launch scripts to run the JS compile, although I think it is possible to
> have a way to fall back to the current mechanism of SWF-only compilation
> and use the separate launch script if folks can't upgrade.
>
>
IMHO, for FlexJS that is new tech we should not be looking at FB anymore.
I understand it for old Flex SDK, legacy SDK goes with legacy IDE....is
right for me
But considering FlexJS, please we should concentrate on newer options begin
developed
with FlexJS...
So that's question #2: Can I start replacing HTML with Basic?
>
>
I think yes, and I want to suggest something here. I created some basic
HTML tags (span, a, div, h1,...)
I think we should separate that tags for normal SDK components like
js:Container, js:Button...
those tags are the most basic structures, and FlexJS component is somewhat
the immediate next level.
In cases like MDL, I could depend it only from basic tags and not from
FlexJS component.
Both avoiding actual confusion of user trying to use both a the time and
better structuring and removing things
People will Neve use (or should never use). And if they want it...PAYG and
introduce it in your build and your code.
Makes that sense?
> question #3: Any objections to moving from one SWC per library to two?
>
>
It seems ok to me at all. And this should remove weight as well removing
dependencies that are not used never in the end
> Any objections to supporting "AUTO" as a special value?
>
>
Here can't help since don't know exactly what's what Fred did
Thanks!
Carlos
--
Carlos Rovira
http://about.me/carlosrovira
AW: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
It's currently not generated but taken from src/main/resources/config.xml statically
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: Alex Harui <ah...@adobe.com>
Datum: 31.01.17 21:48 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
On 1/31/17, 12:43 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Would it be a valid compromise to have two Cordova outputs … one that
>dumps the config.xml and one that also runs Cordova?
>I could live with that. Then I could continue to run Cordova in the
>packaging phase.
Is there already a config.xml being generated? WE can certainly code up
an option to generate some sort of output information file. I'm just
wondering if there is a standard for that already.
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
On 1/31/17, 12:43 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Would it be a valid compromise to have two Cordova outputs … one that
>dumps the config.xml and one that also runs Cordova?
>I could live with that. Then I could continue to run Cordova in the
>packaging phase.
Is there already a config.xml being generated? WE can certainly code up
an option to generate some sort of output information file. I'm just
wondering if there is a standard for that already.
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Would it be a valid compromise to have two Cordova outputs … one that dumps the config.xml and one that also runs Cordova?
I could live with that. Then I could continue to run Cordova in the packaging phase.
Chris
Am 31.01.17, 21:23 schrieb "Alex Harui" <ah...@adobe.com>:
On 1/31/17, 11:51 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>So if I understand you correctly, FlexJS would be outputting an
>“apk”-file because it invokes Cordova internally?
>
>I would vote -1 on that.
>
>The problem here is that we are tightly coupling FlexJS and Cordova. We
>then have one execution, that does generation, compilation and packaging
>(Maven terms) in one step … I would like to keep the compilation and the
>packaging separate. Wouldn’t it be possible to generate the Cordova
>configuration containing the plugins needed in the compilation of a
>“type=cordova” compilation and to use that later on in the packaging
>phase of the build?
>
>As an alternative, in maven we could use a dedicated packaging type to
>automate the configuration of flexjs-maven-plugin and the
>cordova-maven-plugin to do what currently I’m manually doing in the
>examples if you activate the “with-cordova” Maven profile. On the Ant
>target you could integrate the call to Cordova, but I would not like to
>see this Cordova invocation in the compiler itself.
>
>For example, when activating the “with-cordova” profile, in
>“flexjs-framework/examples/flexjs/CordovaCameraExample/target/template/pla
>tforms/android/build/outputs/apk/android-debug.apk” the maven build
>produces the Android APK version of the application with Cordova. But
>when I just tried installing the application for the first time, this
>didn’t quite work as expected, so I would be glad for some assistance on
>what’s going wrong there. If the compiler now produced the config.xml as
>output and cordova would just pick that up, that would be great, but I
>would not like the compiler to do any more.
Well, it depends on what you mean by "compiler". Already, when you run
MXMLJSC from the command-line, it "compiles" by taking a source file and
generating an output file for it, then it packages the output files into a
"web-site" via the MXMLFlexJSPublisher class that copies all of the Google
Closure Library files and the various JS files from the SWC and generates
an index.html file.
MXMLC generates ABC files in memory for each .AS file, then packages it
into a SWF. But it currently doesn't create an index.html file. You have
to do that yourself or Flash Builder and other IDEs seem to know how to
create the html file.
In this new branch, there are many more "clients". MXMLJSC becomes a
shell that calls other clients. The default client, MXMLJSCFlex, does
what MXMLJSC does today. It takes the source files and generates JS
output for them, then calls MXMLFlexJSPublisher to copy the GCL files and
JS files from the SWC and generates the html file.
For Cordova, I am proposing to add yet another client called
MXMLJSCFlexCordova. It will run the same compile step, but then package
via MXMLFlexJSCordovaPublisher which will call Cordova CLI.
I believe that if I tweaked the CompileJSMojo to call MXMLJSCFlex, there
would be no dependencies on any code that calls Cordova CLI. And the code
to call Cordova CLI will probably just use Exec instead of calling any
Cordova JARs so these bits work in a NPM distribution. It could be that
the Maven distribution never publishes MXMLJSCFlexCordova since the Maven
way to build a Cordova app is to use POMs and Maven.
My goal is to have IDEs like Flash Builder, which default to just calling
a compiler, which today generates a runnable SWF, to be able to generate a
runnable web-site and/or a runnable mobile app without any extra steps for
the user. I don't know of a way to add another step to what the IDEs know
how to do.
I did notice that Maven has a packaging phase and have wondered if there
is yet another refactor needed to break the packaging/publishing out into
more independent modules so Maven could call them individually during a
packaging phase but Ant and IDE clients would integrate them together.
We could pass information from the compiler to the packager/publisher via
XML or some other output file if that's helpful. Is there a standard for
doing that? Right now it saves time to share data structures but it
doesn’t have to be that way.
Thoughts?
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
On 1/31/17, 11:51 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>So if I understand you correctly, FlexJS would be outputting an
>“apk”-file because it invokes Cordova internally?
>
>I would vote -1 on that.
>
>The problem here is that we are tightly coupling FlexJS and Cordova. We
>then have one execution, that does generation, compilation and packaging
>(Maven terms) in one step … I would like to keep the compilation and the
>packaging separate. Wouldn’t it be possible to generate the Cordova
>configuration containing the plugins needed in the compilation of a
>“type=cordova” compilation and to use that later on in the packaging
>phase of the build?
>
>As an alternative, in maven we could use a dedicated packaging type to
>automate the configuration of flexjs-maven-plugin and the
>cordova-maven-plugin to do what currently I’m manually doing in the
>examples if you activate the “with-cordova” Maven profile. On the Ant
>target you could integrate the call to Cordova, but I would not like to
>see this Cordova invocation in the compiler itself.
>
>For example, when activating the “with-cordova” profile, in
>“flexjs-framework/examples/flexjs/CordovaCameraExample/target/template/pla
>tforms/android/build/outputs/apk/android-debug.apk” the maven build
>produces the Android APK version of the application with Cordova. But
>when I just tried installing the application for the first time, this
>didn’t quite work as expected, so I would be glad for some assistance on
>what’s going wrong there. If the compiler now produced the config.xml as
>output and cordova would just pick that up, that would be great, but I
>would not like the compiler to do any more.
Well, it depends on what you mean by "compiler". Already, when you run
MXMLJSC from the command-line, it "compiles" by taking a source file and
generating an output file for it, then it packages the output files into a
"web-site" via the MXMLFlexJSPublisher class that copies all of the Google
Closure Library files and the various JS files from the SWC and generates
an index.html file.
MXMLC generates ABC files in memory for each .AS file, then packages it
into a SWF. But it currently doesn't create an index.html file. You have
to do that yourself or Flash Builder and other IDEs seem to know how to
create the html file.
In this new branch, there are many more "clients". MXMLJSC becomes a
shell that calls other clients. The default client, MXMLJSCFlex, does
what MXMLJSC does today. It takes the source files and generates JS
output for them, then calls MXMLFlexJSPublisher to copy the GCL files and
JS files from the SWC and generates the html file.
For Cordova, I am proposing to add yet another client called
MXMLJSCFlexCordova. It will run the same compile step, but then package
via MXMLFlexJSCordovaPublisher which will call Cordova CLI.
I believe that if I tweaked the CompileJSMojo to call MXMLJSCFlex, there
would be no dependencies on any code that calls Cordova CLI. And the code
to call Cordova CLI will probably just use Exec instead of calling any
Cordova JARs so these bits work in a NPM distribution. It could be that
the Maven distribution never publishes MXMLJSCFlexCordova since the Maven
way to build a Cordova app is to use POMs and Maven.
My goal is to have IDEs like Flash Builder, which default to just calling
a compiler, which today generates a runnable SWF, to be able to generate a
runnable web-site and/or a runnable mobile app without any extra steps for
the user. I don't know of a way to add another step to what the IDEs know
how to do.
I did notice that Maven has a packaging phase and have wondered if there
is yet another refactor needed to break the packaging/publishing out into
more independent modules so Maven could call them individually during a
packaging phase but Ant and IDE clients would integrate them together.
We could pass information from the compiler to the packager/publisher via
XML or some other output file if that's helpful. Is there a standard for
doing that? Right now it saves time to share data structures but it
doesn’t have to be that way.
Thoughts?
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
So if I understand you correctly, FlexJS would be outputting an “apk”-file because it invokes Cordova internally?
I would vote -1 on that.
The problem here is that we are tightly coupling FlexJS and Cordova. We then have one execution, that does generation, compilation and packaging (Maven terms) in one step … I would like to keep the compilation and the packaging separate. Wouldn’t it be possible to generate the Cordova configuration containing the plugins needed in the compilation of a “type=cordova” compilation and to use that later on in the packaging phase of the build?
As an alternative, in maven we could use a dedicated packaging type to automate the configuration of flexjs-maven-plugin and the cordova-maven-plugin to do what currently I’m manually doing in the examples if you activate the “with-cordova” Maven profile. On the Ant target you could integrate the call to Cordova, but I would not like to see this Cordova invocation in the compiler itself.
For example, when activating the “with-cordova” profile, in
“flexjs-framework/examples/flexjs/CordovaCameraExample/target/template/platforms/android/build/outputs/apk/android-debug.apk” the maven build produces the Android APK version of the application with Cordova. But when I just tried installing the application for the first time, this didn’t quite work as expected, so I would be glad for some assistance on what’s going wrong there. If the compiler now produced the config.xml as output and cordova would just pick that up, that would be great, but I would not like the compiler to do any more.
Chris
Am 31.01.17, 20:08 schrieb "Alex Harui" <ah...@adobe.com>:
On 1/31/17, 10:16 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Alex,
>
>I’ll have a look at the changes and eventually try to prepare the maven
>plugin for these changes.
In theory, MXMLJSC is backwards compatible. I will try to remember to
make sure of that before merging to develop.
Longer term, I leave it up to you and others to decide if the Maven
support should be tweaked. In some ways, MXMLJSC and the compiler.targets
option may only be needed for non-Maven users, especially in IDEs where
you want one launch of the compiler to compile against different API sets.
If I understand Maven correctly, you can already do that with Maven by
having the POM dictate to run the various compiler "executions".
>
>Just to be on the safe side … with “cordova” you mean producing a
>directory that I can pass into cordova. Not include the cordova
>functionality in Flex, correct?
IMO, the goal is to produce, for Cordova for Android, a .apk file. You
shouldn't have to pass anything into Cordova. We pretty much know the
steps are going to be the same every time so why make you do those steps
some other way. I was going to call Cordova CLI to do it so it works in
the Node distribution. Again this might be only for non-Maven users. The
key here is that one of the pain points around Cordova is remembering to
add the various plugins to your Cordova Project. Because the FlexJS
Publisher visits every .JS file, it is possible that on the visit we can
see that a plugin is needed and automatically add the plugin. But maybe
in Maven for Cordova you have to specify the plugin in the POM anyway.
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
On 1/31/17, 10:16 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Alex,
>
>I’ll have a look at the changes and eventually try to prepare the maven
>plugin for these changes.
In theory, MXMLJSC is backwards compatible. I will try to remember to
make sure of that before merging to develop.
Longer term, I leave it up to you and others to decide if the Maven
support should be tweaked. In some ways, MXMLJSC and the compiler.targets
option may only be needed for non-Maven users, especially in IDEs where
you want one launch of the compiler to compile against different API sets.
If I understand Maven correctly, you can already do that with Maven by
having the POM dictate to run the various compiler "executions".
>
>Just to be on the safe side … with “cordova” you mean producing a
>directory that I can pass into cordova. Not include the cordova
>functionality in Flex, correct?
IMO, the goal is to produce, for Cordova for Android, a .apk file. You
shouldn't have to pass anything into Cordova. We pretty much know the
steps are going to be the same every time so why make you do those steps
some other way. I was going to call Cordova CLI to do it so it works in
the Node distribution. Again this might be only for non-Maven users. The
key here is that one of the pain points around Cordova is remembering to
add the various plugins to your Cordova Project. Because the FlexJS
Publisher visits every .JS file, it is possible that on the visit we can
see that a plugin is needed and automatically add the plugin. But maybe
in Maven for Cordova you have to specify the plugin in the POM anyway.
-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
I’ll have a look at the changes and eventually try to prepare the maven plugin for these changes.
Just to be on the safe side … with “cordova” you mean producing a directory that I can pass into cordova. Not include the cordova functionality in Flex, correct?
Chris
Am 31.01.17, 18:41 schrieb "Alex Harui" <ah...@adobe.com>:
OK, I have something working. It is in the "dual" branch I just pushed.
I added a -compiler.targets option. It allows you to specify a list of
targets. I am deprecating -js-output-type. It should still work for now,
but it only specified a single output for JS compilation. With
-compiler.targets, the currently known set of allowed values is:
SWF
JSFlex
JS
JSNode
I've added a JSFlexCordova but haven't implemented it yet. And I haven't
implemented extensibility for this list.
I've added a new 'client' for each new output type. The old MXMLC still
generates the SWF. MXMLJSC is now a shell that calls MXMLC, or one of the
new clients like MXMLJSCFlex and/or MXMLJSCNode and/or MXMLJSCNative.
These clients create the appropriate backend and publisher and do their
work and report back errors. The MXMLJSC shell collects all errors and
reports them. Depending on how you set -compiler.targets, you can specify
SWF compile before FlexJS compile or vice-versa or skip SWF compilation
completely and generate JS only from Flash Builder.
But there is a catch: MXMLJSC requires Java 7 or greater and Flash
Builder is packaged with Java 6. So, in order to use this capability from
FB, you will need to upgrade FB to use Java 7 as in this post [1]. So
that's the first question: Would we want to require folks to upgrade FB
to Java 7? I don't think we can script the upgrade to automate it for
people as there are permissions issues in the process. But currently, I
think it is worth it, since that means you don't have to use separate
launch scripts to run the JS compile, although I think it is possible to
have a way to fall back to the current mechanism of SWF-only compilation
and use the separate launch script if folks can't upgrade.
Using -compiler.targets, I was able to go back to using the Basic.swc and
on the JS compile it told me where I was still using Flash APIs. This was
a main motivator for combining the compilers. Currently the code in
HTML.swc wraps Sprites for the SWF code which I think is now unnecessary.
So that's question #2: Can I start replacing HTML with Basic?
Right now in the Nightly builds, the workflow is to compile your app
against the same set of SWCs for both SWF and JS. Each SWC is packed with
the JS files. But the JS compile is referencing classes in
playerglobal.swc. With these changes, I added new options like
-js-external-library-path and -js-library-path and -js-define so you can
specify a different set of SWCs for the JS compile. I think that's better
because then you don't have Flash-only classes in the JS compile. But it
means that a library is no longer one SWC. We'd need to distribute both
Core.swc and CoreJS.swc and so forth. Same for third-parties. So that's
question #3: Any objections to moving from one SWC per library to two?
IMO it is worth it as it is cleaner: You are compiling each SWC against
the true API set for that platform.
The -js-define allows you to specify different conditional compile flags
for JS vs SWF, but I copied the approach Fred took a while back and
allowed using -define=COMPILE::SWF,AUTO and -define=COMPILE::JS,AUTO and
the compiler clients will set the appropriate defaults. So question #4:
Any objections to supporting "AUTO" as a special value?
Thoughts?
-Alex
[1]
http://blogs.adobe.com/flashplayer/2016/09/running-adobe-flash-builder-on-m
ac-with-java-78.html#sthash.3knlDhRz.dpbs
On 1/13/17, 9:33 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Back to working on this again...
>
>Currently, there are "clients" like MXMLJSC, COMPJSC, and ASDOCJSC. You
>launch one of these clients. Then you specify (via -js-output-type) what
>"backend" you want the client to use. A backend supplies an "emitter"
>that walks the AST and generates some sort of output. These "backends"
>also currently supply a "publisher" that packages up the output.
>
>I think going forward, there may be a need to have different publishers
>for the same backend/emitter. For example, it might turn out to be
>beneficial to specify a Cordova publisher that knows how to place the
>output and add Cordova plugins to a Cordova project structure. Right now
>we have an Ant script and it doesn't have an extensible way of adding
>Cordova plugins. A Cordova-specific publisher could examine the JS output
>and detect directives to add certain plugins to the Cordova project.
>That could be a significant time-saver for folks building Cordova apps
>with FlexJS.
>
>Then there is the main goal of this thread which is to allow the developer
>(especially the developer using an IDE) to launch a single client and run
>both a SWF compile and a JS compile. SWF compilation is currently done
>with a different set of clients (MXMLC and COMPC).
>
>If I understand Chris's suggestion below, it might be better to have a new
>client for each backend. So, instead of MXMLJSC with js-output-type=NODE
>and MXMLJSC with js-output-type=FLEXJS, we'd have MXMLNODEJSC and
>MXMLFLEXJSC clients and no -js-output-type parameter.
>
>Now having an additional switch for the publisher makes this a bit more
>complex. We might then have an MXMLFLEXJSCCORDOVA as well that knows how
>to output to Cordova projects. What do folks think of this idea?
>
>The backend would no longer be responsible for a publisher. They would be
>separate entities integrated by a client.
>
>Then for Flash Builder, the flex-compiler-oem jar would simply launch more
>than one of these clients and aggregate the output.
>
>Thoughts?
>-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
OK, I have something working. It is in the "dual" branch I just pushed.
I added a -compiler.targets option. It allows you to specify a list of
targets. I am deprecating -js-output-type. It should still work for now,
but it only specified a single output for JS compilation. With
-compiler.targets, the currently known set of allowed values is:
SWF
JSFlex
JS
JSNode
I've added a JSFlexCordova but haven't implemented it yet. And I haven't
implemented extensibility for this list.
I've added a new 'client' for each new output type. The old MXMLC still
generates the SWF. MXMLJSC is now a shell that calls MXMLC, or one of the
new clients like MXMLJSCFlex and/or MXMLJSCNode and/or MXMLJSCNative.
These clients create the appropriate backend and publisher and do their
work and report back errors. The MXMLJSC shell collects all errors and
reports them. Depending on how you set -compiler.targets, you can specify
SWF compile before FlexJS compile or vice-versa or skip SWF compilation
completely and generate JS only from Flash Builder.
But there is a catch: MXMLJSC requires Java 7 or greater and Flash
Builder is packaged with Java 6. So, in order to use this capability from
FB, you will need to upgrade FB to use Java 7 as in this post [1]. So
that's the first question: Would we want to require folks to upgrade FB
to Java 7? I don't think we can script the upgrade to automate it for
people as there are permissions issues in the process. But currently, I
think it is worth it, since that means you don't have to use separate
launch scripts to run the JS compile, although I think it is possible to
have a way to fall back to the current mechanism of SWF-only compilation
and use the separate launch script if folks can't upgrade.
Using -compiler.targets, I was able to go back to using the Basic.swc and
on the JS compile it told me where I was still using Flash APIs. This was
a main motivator for combining the compilers. Currently the code in
HTML.swc wraps Sprites for the SWF code which I think is now unnecessary.
So that's question #2: Can I start replacing HTML with Basic?
Right now in the Nightly builds, the workflow is to compile your app
against the same set of SWCs for both SWF and JS. Each SWC is packed with
the JS files. But the JS compile is referencing classes in
playerglobal.swc. With these changes, I added new options like
-js-external-library-path and -js-library-path and -js-define so you can
specify a different set of SWCs for the JS compile. I think that's better
because then you don't have Flash-only classes in the JS compile. But it
means that a library is no longer one SWC. We'd need to distribute both
Core.swc and CoreJS.swc and so forth. Same for third-parties. So that's
question #3: Any objections to moving from one SWC per library to two?
IMO it is worth it as it is cleaner: You are compiling each SWC against
the true API set for that platform.
The -js-define allows you to specify different conditional compile flags
for JS vs SWF, but I copied the approach Fred took a while back and
allowed using -define=COMPILE::SWF,AUTO and -define=COMPILE::JS,AUTO and
the compiler clients will set the appropriate defaults. So question #4:
Any objections to supporting "AUTO" as a special value?
Thoughts?
-Alex
[1]
http://blogs.adobe.com/flashplayer/2016/09/running-adobe-flash-builder-on-m
ac-with-java-78.html#sthash.3knlDhRz.dpbs
On 1/13/17, 9:33 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Back to working on this again...
>
>Currently, there are "clients" like MXMLJSC, COMPJSC, and ASDOCJSC. You
>launch one of these clients. Then you specify (via -js-output-type) what
>"backend" you want the client to use. A backend supplies an "emitter"
>that walks the AST and generates some sort of output. These "backends"
>also currently supply a "publisher" that packages up the output.
>
>I think going forward, there may be a need to have different publishers
>for the same backend/emitter. For example, it might turn out to be
>beneficial to specify a Cordova publisher that knows how to place the
>output and add Cordova plugins to a Cordova project structure. Right now
>we have an Ant script and it doesn't have an extensible way of adding
>Cordova plugins. A Cordova-specific publisher could examine the JS output
>and detect directives to add certain plugins to the Cordova project.
>That could be a significant time-saver for folks building Cordova apps
>with FlexJS.
>
>Then there is the main goal of this thread which is to allow the developer
>(especially the developer using an IDE) to launch a single client and run
>both a SWF compile and a JS compile. SWF compilation is currently done
>with a different set of clients (MXMLC and COMPC).
>
>If I understand Chris's suggestion below, it might be better to have a new
>client for each backend. So, instead of MXMLJSC with js-output-type=NODE
>and MXMLJSC with js-output-type=FLEXJS, we'd have MXMLNODEJSC and
>MXMLFLEXJSC clients and no -js-output-type parameter.
>
>Now having an additional switch for the publisher makes this a bit more
>complex. We might then have an MXMLFLEXJSCCORDOVA as well that knows how
>to output to Cordova projects. What do folks think of this idea?
>
>The backend would no longer be responsible for a publisher. They would be
>separate entities integrated by a client.
>
>Then for Flash Builder, the flex-compiler-oem jar would simply launch more
>than one of these clients and aggregate the output.
>
>Thoughts?
>-Alex
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
Back to working on this again...
Currently, there are "clients" like MXMLJSC, COMPJSC, and ASDOCJSC. You
launch one of these clients. Then you specify (via -js-output-type) what
"backend" you want the client to use. A backend supplies an "emitter"
that walks the AST and generates some sort of output. These "backends"
also currently supply a "publisher" that packages up the output.
I think going forward, there may be a need to have different publishers
for the same backend/emitter. For example, it might turn out to be
beneficial to specify a Cordova publisher that knows how to place the
output and add Cordova plugins to a Cordova project structure. Right now
we have an Ant script and it doesn't have an extensible way of adding
Cordova plugins. A Cordova-specific publisher could examine the JS output
and detect directives to add certain plugins to the Cordova project.
That could be a significant time-saver for folks building Cordova apps
with FlexJS.
Then there is the main goal of this thread which is to allow the developer
(especially the developer using an IDE) to launch a single client and run
both a SWF compile and a JS compile. SWF compilation is currently done
with a different set of clients (MXMLC and COMPC).
If I understand Chris's suggestion below, it might be better to have a new
client for each backend. So, instead of MXMLJSC with js-output-type=NODE
and MXMLJSC with js-output-type=FLEXJS, we'd have MXMLNODEJSC and
MXMLFLEXJSC clients and no -js-output-type parameter.
Now having an additional switch for the publisher makes this a bit more
complex. We might then have an MXMLFLEXJSCCORDOVA as well that knows how
to output to Cordova projects. What do folks think of this idea?
The backend would no longer be responsible for a publisher. They would be
separate entities integrated by a client.
Then for Flash Builder, the flex-compiler-oem jar would simply launch more
than one of these clients and aggregate the output.
Thoughts?
-Alex
On 12/5/16, 8:52 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Yes I do ... I did a lot of „networking“ with the maven guys in Seville.
>It seems that I managed to get the point I didn’t seem to manage via
>emails.
>Currently I am using different sets of libaries based upon classifiers,
>but that’s just a temporary hack. I am hoping that I will be able to make
>Maven more polyglot in the near future and then we will probably have a
>complete new world of possibilities ;-)
>
>Chris
>
>Am 05.12.16, 17:07 schrieb "Alex Harui" <ah...@adobe.com>:
>
> Thanks Chris, that's helpful. Do you have any thoughts on how to
>manage
> two different sets of libraries, one for SWF compile, one for JS
>compile?
>
> Thanks,
> -Alex
>
> On 12/5/16, 12:44 AM, "Christofer Dutz" <ch...@c-ware.de>
>wrote:
>
> >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" <ah...@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" <ah...@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"
><ch...@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 <ah...@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" <jo...@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.rovira@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
> > >>>><ch...@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 <jo...@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.dutz@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 <ah...@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"
><jo...@gmail.com>
> >wrote:
> > >>>> > >
> > >>>> > > >That would be ideal!
> > >>>> > > >
> > >>>> > > >- Josh
> > >>>> > > >
> > >>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui"
><ah...@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" <ah...@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"
> > >>>><ch...@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.
> > >>>>
> > >>
> > >
> >
> >
> >
>
>
>
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
Yes I do ... I did a lot of „networking“ with the maven guys in Seville. It seems that I managed to get the point I didn’t seem to manage via emails.
Currently I am using different sets of libaries based upon classifiers, but that’s just a temporary hack. I am hoping that I will be able to make Maven more polyglot in the near future and then we will probably have a complete new world of possibilities ;-)
Chris
Am 05.12.16, 17:07 schrieb "Alex Harui" <ah...@adobe.com>:
Thanks Chris, that's helpful. Do you have any thoughts on how to manage
two different sets of libraries, one for SWF compile, one for JS compile?
Thanks,
-Alex
On 12/5/16, 12:44 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>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" <ah...@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" <ah...@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" <ch...@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 <ah...@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" <jo...@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.rovira@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
> >>>><ch...@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 <jo...@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.dutz@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 <ah...@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" <jo...@gmail.com>
>wrote:
> >>>> > >
> >>>> > > >That would be ideal!
> >>>> > > >
> >>>> > > >- Josh
> >>>> > > >
> >>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui" <ah...@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" <ah...@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"
> >>>><ch...@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.
> >>>>
> >>
> >
>
>
>
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Alex Harui <ah...@adobe.com>.
Thanks Chris, that's helpful. Do you have any thoughts on how to manage
two different sets of libraries, one for SWF compile, one for JS compile?
Thanks,
-Alex
On 12/5/16, 12:44 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>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" <ah...@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" <ah...@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" <ch...@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 <ah...@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" <jo...@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.rovira@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
> >>>><ch...@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 <jo...@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.dutz@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 <ah...@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" <jo...@gmail.com>
>wrote:
> >>>> > >
> >>>> > > >That would be ideal!
> >>>> > > >
> >>>> > > >- Josh
> >>>> > > >
> >>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui" <ah...@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" <ah...@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"
> >>>><ch...@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.
> >>>>
> >>
> >
>
>
>
Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW:
[FalconJX][FlexJS] COMPJSC and Build order)
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ah...@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" <ah...@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" <ch...@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 <ah...@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" <jo...@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.rovira@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
>>>><ch...@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 <jo...@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.dutz@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 <ah...@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" <jo...@gmail.com> wrote:
>>>> > >
>>>> > > >That would be ideal!
>>>> > > >
>>>> > > >- Josh
>>>> > > >
>>>> > > >On Oct 1, 2016 10:47 PM, "Alex Harui" <ah...@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" <ah...@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"
>>>><ch...@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.
>>>>
>>
>