I think that test has a @ignore on the entire test class. -Alex
On 3/22/16, 12:32 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >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 ;-) > >Chris > >________________________________________ >Von: carlos.rov...@gmail.com <carlos.rov...@gmail.com> im Auftrag von >Carlos Rovira <carlos.rov...@codeoscopic.com> >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.d...@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.d...@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.pn >>g >> >> 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.d...@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 <aha...@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.d...@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 >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.
