The ant_on_air stuff is brand new and full of bugs. I thought Air followed redirects. There must be code in the installer that does the right thing. Feel free to find it and add it if it needs it.
On 12/11/13 4:30 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >A different topic : > I have checked ant_on_air Get.as, it seems that it's lacking the >url-forwarding management required for downloading from eg. sourceforge >mirrors >We needed that for OSMF.swc 2.0 download in the current installer. > >Ant Get task does it, but it's based on powerful java UrlProvider. >http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/ >taskdefs/Get.java?view=markup > >I don't think we need to be at the same level, but at least it should >work on sourceforge downloaded, maybe with some hard-coded stuff... > >WDYT? > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] >Envoyé : jeudi 12 décembre 2013 00:53 >À : dev@flex.apache.org >Objet : Re: Installer Revisited > >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 >>> >> >
