flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: AW: [FALCONJX] Some help with the externs
Date Tue, 22 Mar 2016 19:32:03 GMT
Another thing I just noticed while separating the tests that I need to adjust from the ones
I need to move:
Ho can the test TestExternJQuery pass? In the configure it creates a path:
        String coreRoot = ExternalsTestUtils.EXTERNAL_JS_DIR.getAbsolutePath();
        config.addExternal(coreRoot + "/jquery-1.9.js");

The stupid thing is this evaluates to "../externs/js/externs/jquery-1.9.js" but this file
does not exist as it should be "../externs/jquery/externs/jquery-1.9.js" ... so I would like
to state that I mistrust this test ;-)


Von: carlos.rovira@gmail.com <carlos.rovira@gmail.com> im Auftrag von Carlos Rovira
Gesendet: Sonntag, 20. März 2016 09:29
An: dev@flex.apache.org
Betreff: Re: AW: [FALCONJX] Some help with the externs

Amazing work Chris! Thanks to share your progress! :)

2016-03-19 14:33 GMT+01:00 Christofer Dutz <christofer.dutz@c-ware.de>:

> YESSSS!!!!!
> I finally managed to port the builds for ALL externs to maven. I was
> thinking about how I could de-couple the compiler and the maven plugin till
> I noticed that this was exactly the problem I always had with Flexmojos and
> what I created the Flex tool-api for. With this it was super easy to create
> universal Maven plugins for externc and mxmlc.
> Currently the maven build is far from perfect ... currently I reference
> the js.swc via relative paths, which is a super no-go for production, but
> at least I can build and as Ant used relative paths it's not even a step
> back :-)
> Also every module is currently still a "jar" project and hence maven
> produces "jar" files in the target, all of which are probably completely
> empty. In order to address this I will actually have to provide a custom
> lifecycle mapping which will make the hack more and more real flex support
> for maven.
> Now I have to find out how to separate the tests that currently use other
> parts of the build and move them into a dedicated "testsuite" module.
> But I think for now the hardest steps have been taken.
> Now I'm going to actually start programming my Cyborg ... don't want to
> arrive at ApacheCon with nothing to show ;-)
> Chris
> ________________________________________
> Von: Christofer Dutz <christofer.dutz@c-ware.de>
> Gesendet: Samstag, 19. März 2016 11:02
> An: dev@flex.apache.org
> Betreff: AW: AW: [FALCONJX] Some help with the externs
> Ok ... so have a look at this image :-)
> http://s21.postimg.org/lx4dux0jr/Bildschirmfoto_2016_03_19_um_10_53_31.png
> I finally managed to finish a first build of an extern swc, using Maven
> and using my brand-new externc and compiler Maven plugins. My plugins are
> currently a simple prototype wich I am hoping to extend to support
> everything needed to build the test cases in the test suite. As the rest of
> the compiler blows up if you leave the 100% correct path at least I have no
> pressure to make it perfect ... so I'll stick to "it doesn't blow up if you
> do everything correct"-strategy for now, which makes things a lot simpler
> (but also unusable for others)
> Currently my plugins are tightly coupled with compiler and compiler.jx ...
> this would complicate the build, so I think I'm going to use my Tool-API to
> decouple them. And I am going to write the plugin in the falcon repo as it
> makes things very complicated as long as not everything is released at
> least once.
> Chris
> ________________________________________
> Von: Christofer Dutz <christofer.dutz@c-ware.de>
> Gesendet: Samstag, 19. März 2016 09:19
> An: dev@flex.apache.org
> Betreff: AW: AW: [FALCONJX] Some help with the externs
> I'm using this one:
>                     <dependency>
>                         <groupId>com.google.javascript</groupId>
>                         <artifactId>closure-compiler-externs</artifactId>
>                         <version>v20150609</version>
>                     </dependency>
> But your post was very valuable input as I re-checked and found out that
> the closure compiler version has changed. So I updated to that version an
> now I do have a browser directory and the number of errors went down to 2
> ;-) ... thanks Alex :-)
> Guess I sticked to the versions I once found out ant stuck into my
> hand-written poms I used to create maven bundles. Should double check all
> of them, if there were version updates.
> Chris
> ________________________________________
> Von: Alex Harui <aharui@adobe.com>
> Gesendet: Freitag, 18. März 2016 21:18
> An: dev@flex.apache.org
> Betreff: Re: AW: [FALCONJX] Some help with the externs
> On 3/18/16, 12:15 PM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:
> >Currently I'm working on the last module "js". Unfortunately this seems
> >to be the "playerglobal" of FlexJS :-( ... one thing I noticed, was that
> >the "externs/js/externs" directory contains the content of the
> >externs.zip which is embedded in google's closure compiler. So far so
> >good, but looking at the build, the zip is extracted to the
> >"externs/js/externs" directory, but strangely the files are structured
> >with a "browser" directory. The original zip however doesn't contain any
> >directories, so where does that directory structure come from?
> My copy of externs.zip expands to have a browser folder.  Older versions
> didn't.  And it might be that newer ones don't as well.  Which version of
> Google Closure Compiler are you using?
> -Alex


Carlos Rovira
Director General
M: +34 607 22 60 05

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
View raw message