Found it: ant_on_air is in flex_utility repo. -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 11 décembre 2013 23:54 À : dev@flex.apache.org Objet : RE: Installer Revisited
Hi Alex, I like better the first idea (that the script is in the first package to download, in a known place). Furthermore, that would merge the logic for building the SDK manually and building from the installer in one single build file, right ? One question: what is "ant_on_air"? I googled for it, but found nothing. Is it something already existing, or that has to be done yet? Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 11 décembre 2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited Hi, I've checked in enough stuff into flex-utilities/ant_on_air to try to build out SDK installation in Ant. My plan is to create an ant script that does what the current installer does, make sure it works in Ant, then try to get it to work in ant_on_air. Of course, that will be a bit ugly since Ant only supports a simple prompt to get license acceptance. But once that works, then I'll create a custom task that populates the licensing dialog in the installer. Meanwhile, I've been pondering what the workflow should really be the release manager and for installer users and am interested in what others think. Right now my understanding is that we post an xml file on the flex.apache.org website that lists the versions of Apache Flex that are available for install, and the logic for installing is in the Installer itself. With ant_on_air, we have the opportunity to move the install logic to a separate script. The Installer code would then only do things that are far less-likely to change, like manage a licensing dialog box, show a progress bar, offer a set of choices, and via ant_on_air, download files, copy files, etc. That sort of makes me want to bundle the install script into the release packages instead of having to manage what will become a growing pile of separate scripts as we create scripts for falcon-only installation, FlexJS, and the current SDK. If we do that, the installer would be given a list of convenience binary packages which have a build.xml in them with a "installForIDE" target. The user picks a binary package, and the installer downloads the package, validates it, expands it, and runs the installForIDE target on the build.xml it finds in the package via ant_on_air. A model that is more similar to what the installer does now is that the installer has a list of scripts it knows how to run and simply launches ant_on_air on that script which downloads the binary package, validates it, expands it, etc. But if we do that, where should these scripts live in our repo? It feels funny to take them from the sdk or asjs repo and not have them go in the release packages. Should they live in the installer repo? Thoughts? -Alex
