>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.
I don't know either if AIR follows redirects or not, but the way it does was not enough for downloading from sourceforge and we had to implement a specific solution. My concern is that it's really specific, and difficult to make generic. Another point is that current Installer has conditional logic ( eg. if already downloaded, don't download again) that will need to be implemented in ant_on_air. It's also missing <parallel> functionality, that would speed up downloads. And I am sure that we will discover other things... As you say, it's brand new stuff. ------ So may I open the discussion on an alternative approach: After all, do we absolutely need that the installer be and AIR app? The ant "core" lib is not that big (a few MB) so maybe we could build the installer as a JAVA GUI app instead of an AIR app, that embeds the ANT lib. I am not saying this will be easy, but at least it will be guaranteed to have the same behavior, and opens up a full range of possibilities. Thoughts ? Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 12 décembre 2013 01:42 À : dev@flex.apache.org Objet : Re: Installer Revisited 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/a >nt/ >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 >>> >> >
