This ant_on_air stuff doesn't replace the current installer, the installer will be upgraded to use it, and will use its license dialog, progress bar and other UI to show the progress of the script.
The way I see it, we need installers for not only the current SDK, but also FlexJS and Falcon-only upgrades to the current SDK, and potentially, installers for BlazeDS-only, FlexUnit, and hopefully someday, Swiz. It feels like we do installer releases almost every time we do an SDK release, and each installer release requires this dance where we ask folks to make the Linux, Mac and Windows AIR packages. IMO, the fewer times we do this the better, so by moving the logic into a script that goes in the release packages for the SDK, FlexJS, Falcon, etc, we will save time in the end. In 2014, we'll probably be pumping out FlexJS and Falcon releases quite frequently, and hopefully folks will be contributing more and more localized languages for those installs. It will be nice to not have to cut new Installer releases as often. I'm sure there'll be a few as we find and fix bugs in the ant_on_air stuff. Also, there is no goal at present to make ant_on_air a full equivalent of ant. All I'm really doing is encapsulating the installer functionality into scriptable form but using ant syntax for that script. We'll have a few different targets for the main target the installer runs vs the one that you could run if you had ant installed, but hopefully the vast majority of the steps will be the same. And no current installer functionality should be lost. You can choose which AIR and FP version you want by setting up properties which the installer will pass into the script. -Alex On 12/12/13 1:43 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >>I'm sure none of this is unsolvable, but should we throw away the nice >>installer we have and replaces it with something else when it works >>quite well? Wouldn't the time >be better spent elsewhere eg fixing >>outstanding bugs/JIRA issues? The users don't care if the installer uses >>ant for air under the hood or not but they do care about bugs >being >>fixed. Currently modifying the AS code in the installer isn't that hard. > >I agree that fixing bugs is the current highest priority (and I already >have a lot on my plate). >IMO, Alex was thinking ahead about FlexJS installers, and then thought of >a kind of "generic" installer, which logic would be based on ANT. >Once this installer would be ready for FlexJS, it could also replace the >current Flex SDK installer. >I consider this topic as "preliminary" discussions on what could be done >in the near future. > >Regards, > >Maurice > >-----Message d'origine----- >De : Justin Mclean [mailto:jus...@classsoftware.com] >Envoyé : jeudi 12 décembre 2013 09:52 >À : dev@flex.apache.org >Objet : Re: Installer Revisited > >Hi, > >A few questions: >The installer can also run locally ie not download anything but copy >local files. Can we do this with ant for air? >With ant for air how would be be able to select the AIR and FP version >and only download the correct version? Can we default to current latest >versions? >Would all the licence acceptances be in one step? Can we disable the next >button until all required licences have been accepted? >Can we keep the same nice UI the installer has? Just about all UIs I've >seen that use config files for layout/steps end up looking like they been >designed by developers not designers. > >I'm sure none of this is unsolvable, but should we throw away the nice >installer we have and replaces it with something else when it works quite >well? Wouldn't the time be better spent elsewhere eg fixing outstanding >bugs/JIRA issues? The users don't care if the installer uses ant for air >under the hood or not but they do care about bugs being fixed. Currently >modifying the AS code in the installer isn't that hard. > >Thanks, >Justin
