I have to admit to my shame, that I haven't had one look at the current version, so please forgive me for suggesting something that has allready happened. Perhaps I should download the latest version. I assume it should be structured the way the SDKs will be distributed from now on. As I am currently working on re-deploying all oft he older Releases back down to Flex 2.0.1 it would be best, If I made those deployments support the new structure. This way we wouldn't have a break in the structure :-)
Currently I am using the "playerglobal" library to find out the minimum player version a SDK needs to work. Will this information be provided any other way from now on? Chris -----Ursprüngliche Nachricht----- Von: Carol Frampton [mailto:cfram...@adobe.com] Gesendet: Donnerstag, 17. Mai 2012 19:09 An: flex-dev@incubator.apache.org Betreff: Re: AW: Preliminary release candidate of Apache Flex 4.8.0 (for developers only) On 5/17/12 12 :41PM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> wrote: >Hi, > >I am currently working on a tool to automatically convert a flex sdk >into a mavenized form that I can use together with my flexmojos maven builds. > >While I was working on this, I could never understand, why the >playerglobal and airglobal stuff is actually located inside the Flex >SDK framework directory. As far as I understood it, it actually has >nothing to do with the actual Flex framework and is more part of the >runtime. I guess Adobe will still be using Flash Player and >playerglobal as they are provided by Adobe and Apache doesn't do any >developing in this sector. Am I correct? > >In my tool I decided to deploy the playerglobal and airglobal parallel >to the runtimes, this also avoided the version confusions in flexmojos: >Now you select which flex sdk you want and what player version. > >Just to ad my 50ct to this discussion about the playerglobal location. > >Chris > Chris, I'm not sure how much you've been following the recent changes. In the Apache world, AIR and playerglobal should not be within the Flex directory structure and we've moved them out. There are either environment variables, and/or properties in an env.property file, that can be used to specify the locations. The property file path needs a tad more work which I've done but not submitted yet. FlashBuilder, on the other hand, is very intertwined with the Flex SDK, and expects/demands, everything live in the same directory structure. Carol > > > > > >-----Ursprüngliche Nachricht----- >Von: Carol Frampton [mailto:cfram...@adobe.com] >Gesendet: Dienstag, 15. Mai 2012 15:37 >An: flex-dev@incubator.apache.org >Betreff: Re: Preliminary release candidate of Apache Flex 4.8.0 (for >developers only) > >Justin, > > >On 5/10/12 7 :13PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >> >>I not sure that an environment variable is the best to indicate the >>path to playerglobal.swc but it shoudl be placed in prescribed place >>in the SDK folder. Why? Well if you have multiple versions of the >>Apache SDK configured in Flash Builder which use different versions of >>playerglobal.swc it going to make life a little difficult. > >I've been doing some FlashBuilder integration work for the FlashBuilder >team. I finally get what you are saying about the playerglobal version. >When you change the target version either thru the IDE or on the >command line, the path to playglobal.swc should automagically change. >In flex-config.xml, rather than the current entries which are > > <external-library-path> > <path-element>{playerglobalHome}/playerglobal.swc</path-element> > </external-library-path> > > <path-element>{playerglobalHome}</path-element> > > > > >the proper entries should be > > <external-library-path> > ><path-element>{playerglobalHome}/{targetPlayerMajorVersion}.{targetPlay >erM >i >norVersion}/playerglobal.swc</path-element> > </external-library-path> > > > ><path-element>{playerglobalHome}/{targetPlayerMajorVersion}.{targetPlay >erM >i >norVersion}</path-element> > >The compiler replaces playerglobalHome with PLAYERGLOBAL_HOME >environment variable (or with the change I am sitting on the >env.PLAYERGLOBAL_HOME property in env.properties) and it replaces >{targetPlayerMajorVersion} and {targetPlayerMinorVersion} with the >targetVersion. > > >I think I originally removed the version stuff because it is more >complicated to explain how the directory structure pointed to by >PLAYERGLOBAL_HOME is set up. Minimally you need playerglobal-dir/x.x >where x.x is the value of playerglobal.version in build.properties. > > >What do you think? > >Carol >
