Well I couln't find a config file explicitly telling me which Air version I should use. The generator used to find out which version by comparing the checksum of the airglobal.swc with the checksums of the airglobals bundled in the Air fdks ... unfortunately the Apache FDK didn't have such a swc so I copied the one bundled in the 4.6 FDK (Assuming the Air version should be the same in the parity release).
I would rather have the generator generate the needed Air version based upon some config.xml, but I couldn't find any :-( (Pointers gladly accepted ;-) ) Chris ________________________________________ Von: Frédéric THOMAS [webdoubl...@hotmail.com] Gesendet: Freitag, 2. November 2012 00:37 An: flex-dev@incubator.apache.org Betreff: Re: Compiler Arguments oups, I thought you updated the air version but no :P -----Message d'origine----- From: Frédéric THOMAS Sent: Friday, November 02, 2012 12:23 AM To: flex-dev@incubator.apache.org Subject: Re: AW: AW: AW: AW: AW: Compiler Arguments Good news, especialy for the themes, I've seen as well from the dump file you reported that you updated the air version to the one of the sdk, I reported this change manualy in the generator but I did it quickly, hard coding the version number which is bad, I hope you'll send me a copy as soon as you'll finish. For the namespace, I stayed on com.adobe as otherwize I've been in trouble with some exlusions, I hope I won't run into this problem anymore with the new version. -----Message d'origine----- From: christofer.d...@c-ware.de Sent: Thursday, November 01, 2012 11:53 PM To: flex-dev@incubator.apache.org Subject: AW: AW: AW: AW: AW: Compiler Arguments Well I did a lot of little stuff. - I re-activated the creation oft he config-zip, but left out the themes directory - I finally activated generating the lib-artifacts with their real versions (This is what's causing quite some trouble in FM but without it the FDKs wouldn't be 100% correct) - Now I copy every swc theme and compile every non-swc theme to a swc-theme so all themes are now swc themes - Apache FDKs are generated into the Apache namespace "org.apache.flex" - There were a few glitches with the poms generated for air application ... now all should be good :-) Still 2 tests failling in the testsuite, but I simply have to find a way to automatically get the version of the framework.swc in a given lib. Shouldn't be that hard using my dependency-management extra-poms. So hopefully I'll be able to finish everything on Sunday. Chris -----Ursprüngliche Nachricht----- Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] Gesendet: Donnerstag, 1. November 2012 23:17 An: flex-dev@incubator.apache.org Betreff: Re: AW: AW: AW: AW: Compiler Arguments Chris, What kind of changes did you do in the generator ? If they are importants, I'll be happy to get a fresh copy. For the Apache Con Europe, unfortunatly, I can't (I have to work). -----Message d'origine----- From: christofer.d...@c-ware.de Sent: Thursday, November 01, 2012 10:35 PM To: flex-dev@incubator.apache.org Subject: AW: AW: AW: AW: Compiler Arguments Am I understanding you correctly, that the handling of "-compiler.locale" is correct that way, but the "-metadata.language" should probably only contain the first segment (In this case " es_MX")? Sounds sensible. Think I'll have a look at why this is some times generated. @Mike ... I get failures about every 10 runs of the entire Testsuite (And yes ... having to run it that often really sucks ... but I want to have my new FDKs up and running) By the way ... I did do quite some work on the Flexmojos6 and FDK Generator on the last few days and I think I might be able to finish FM6 and the new Flex FDKs before going zo the Apache Con Europe :-) (See you there?) Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Donnerstag, 1. November 2012 21:57 An: flex-dev@incubator.apache.org Betreff: Re: AW: AW: AW: Compiler Arguments On 11/1/12 1:17 PM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> wrote: > Nope, > > This would be the case if you wanted to add 3 different locales. > If you define es_MX,es_ES,en_US this is more a locale-chain (I reverse > learned this from the unit-test code. Hmm, is there really a difference from in the SDK code-paths for this? I didn't think there was, but I'm not the expert on locales. Anyway, I want to point out your error is not in the locale handling. The arguments to -locale look like they are being handled correctly, but somehow, the same list ends up in -metadata.language. How is that happening? If it is automatically being set up by something, that might need to be changed to create a single string. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui