Yup, makes sense. -Alex
On 12/11/13 3:18 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >>I guess it is a separate question whether the main build.xml should call >>out to an installer.xml like we already do for download.xml. Also, the >>install script >shouldn't have to run custom tasks like compc and mxmlc. >>Hopefully everything is built and then we get other stuff and copy it >>into the right places. But essentially, the script is co-located in the >>binary packages files. > > >* The main build.xml will build the binary package but without the >dependencies (and does all the compc/mxmlc). >This same package would be the first package to be downloaded by the >installer. > >Then there is a secondary build.xml (equivalent to download.xml) located >inside this first package, in a known place, that would basically >download the dependencies and put up everything together to have an >operational SDK. >The secondary build would be called by the installer via ant_on_air >Or could be started manually for a manual build of an operational SDK. >(this secondary build only contains Get, Unzip, Copy, etc...) > >Makes sense ? > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] >Envoyé : jeudi 12 décembre 2013 00:00 >À : dev@flex.apache.org >Objet : Re: Installer Revisited > > > >On 12/11/13 2:53 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >wrote: > >>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 ? >I guess it is a separate question whether the main build.xml should call >out to an installer.xml like we already do for download.xml. Also, the >install script shouldn't have to run custom tasks like compc and mxmlc. >Hopefully everything is built and then we get other stuff and copy it >into the right places. But essentially, the script is co-located in the >binary packages files. > >-Alex >> >>-----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 >> >
