Well you cerainly know how to name a thread to catch my attention ;-) First ... I would deffinitely call playerglobal and airglobal (and whatother swf/swc is needed) NOT a build tool ... they actually do nothing themselves. They are totally as "library" as you can get.
Second, I understand you want to be flexible, but how about having Environment variables, where the build checks, If they are set. If they are set it gives a short message: "Using MY_COOL_VARIABLE=Lalalalalala" to the output (so you actually know the build picked it up). If it's not set it eventually downloads the missing files automatically to a directory and automatically sets the variable to that auto-value. If you need to do more stuff (accept licences etc.) It becomes a little more interactive and guides the user through the process. This way you could have the flexibility you want without requiring us to setup all sorts of "Those @#*$^ Environment Variables" (Especially on CI environments) Yeah ... I know ... that's a lot of work, but hey ... you want to stick to Ant ... Maven automates a lot of the stuff you want to ensure. I guess noone ever checked in his maven local repo (That's where Maven downloads and saves stuff ... that's so totally not inside the project) The funny thing is, that exactly this interactive-guide-the-user-through-the-process-thing is what YOU made me implement for the maven-sdk-converter ;-) If I'm finished with FM7.1 it will have a feature, that depending on the version of playerglobal or airglobal (and in absense of a "flashplayer" or "airruntime" variable) in the module, it will download the Air or Flashplayer matching the library version and run that locally from the current modules "target" directory. This way you can setup a build that runs on any machine with only the requirement to have Java and Maven setup. Ok ... well that's a requirement to Path and Environment-Variables I can live with ;-) Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Samstag, 14. November 2015 07:01 An: dev@flex.apache.org Betreff: Those @#*$^ Environment Variables Hi, Folks are still getting tripped up trying to get prerequisite build tools set up and ready to go. Let’s use this thread to figure out a better solution. I know Chris is going to say “Maven” and I support that, but I still think we can’t require everyone to go to Maven. Some history: There is a concept in the ASF of “build tools”. Build tools and operating systems and runtimes can have proprietary licenses. Other kinds of dependencies must have Apache-compatible licenses or be optional dependencies. One test of whether some thing is a dependency or a build tool is if code from that thing is used at run time or only during the build. So, for Apache Flex, the AIR SDK and Flash SDK (playerglobal.swc) are considered build tools. No code from airglobal.swc or playerglobal.swc is linked into your SWFs and those files don’t get deployed and used by the runtime at run time. As I understand it, that’s one reason our build scripts don’t bring down and install the Adobe SDKs and standalone debugger. I think the consensus was that source package should keep that distinction clear. On the other hand, the Apache Flex SDK Installer does install the Adobe SDKs, but it is dealing with the binary convenience packages which aren’t official ASF releases. In addition, I personally like the fact that the Adobe code can live outside the source package and/or repo folders. That way I know I won’t accidentally commit any of it to the repos. But it does mean that the repos aren’t set up to be IDE-compatible, which has also been a pain point for some folks. However, I think we will have to find some other solution other than copying files into the repo. While the Flex SDK has both a compiler and AS framework in one repo, FalconJX is a separate repo from the FlexJS AS framework (which I think is a good thing) and that sort of means you’ll never get a FlexJS repo setup with both a compiler and AS framework in it. Anyway, back to environment variables. I believe one of the requirements is to allow folks to choose different versions of the Adobe SDKs. But do we need to allow tons of flexibility on where those Adobe files go? Do we need to allow folks to keep more than one version around on their systems? Here are some ideas: 1) require that folks create an adobe folder in c:\ or HOMEPATH on Windows and HOME on Mac 2) further require that the folder structure in the adobe folder is something like air/versionnumber and flash/versionnumber (e.g. air/4.0. The standalone debugger would go in flash/versionnumber as well. 3) #2 allows folks to keep more than one version of an SDK on their machine. But that pretty much means that you have to pass the version number you want to use to the build scripts. If we only required an air and flash without version numbers, the scripts wouldn’t need to figure out what version to use. 4) create scripts that take a version number and create and populate the adobe folder. I still would not fold these into the main build.xml. These scripts will have to ask folks to accept the Adobe licenses before downloading. 5) create something the Apache Flex Installer can install that populates the adobe folder 6) try to get our build scripts to find the air and flash SDKs from an installed Flex or FlexJS SDK. The problem with that is the standalone debugger isn’t part of the install. In sum, if we can assume that the Adobe stuff is going to be in a few known places, we can hopefully eliminate most or all of the pain around this sort of thing and eliminate the requirement for environment variables. Thoughts? -Alex
