I think I’m in the “let’s try Maven” camp as well. I think it’s safe to say that ant is not a clear good fit. Yes. It works, but a lot of us have had trouble with it.
Like Om, I don’t see a difference between requiring ant and requiring maven. The one time I did try Maven to build something, it was really easy. Three commands, and I was done: 1. brew install maven 2. cd to the folder 3. mvn install Seriously, it could not be easier. No configuring things. No setting environment variables. Everything just “works”. However, in order for Maven to be a viable option, a decent number of us need to have a clue how to use it (beyond mvn install). Chris (and maybe Om) is the only one who really knows Maven well enough. If Chris is up to teaching the rest of us what we need to know, I’m all for learning. Harbs On Nov 14, 2015, at 8:01 AM, Alex Harui <aha...@adobe.com> wrote: > 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 > >
