I'm not spending any time on the installer other than occasionally pondering if there is some other workaround we could deploy. I'm waiting on Adobe to put out a 64-bit native installer. IMO, that's the least work on our part, but not sure when Adobe will push that out.
The SSL errors from SourceForge have a workaround that's been posted a few times. The correct solution is to write our own font encoding library. Volunteers are needed. I thought Ant on Windows would work if you used a recent version of Ant. Thanks, -Alex On 7/5/17, 6:13 PM, "Nicholas Kwiatkowski" <que...@apache.org> wrote: >Is anybody actually addressing the issues people have been reporting about >the installer and/or ANT script for Flex SDK 4.16.0? > >Right now I see two major issues that are preventing even people who are >familiar with the SDK from doing installs : > > - In the installer, selecting AIR 25.0 gives users a non-descript "error >1000". This is due toe the md5 checking in the installer running out of >memory > - Trying to install via ANT is also broken under Windows (any version of >AIR SDK). As packaged, it always errors because it tries to install the >MacOS AIR SDK. Additionally, the optional components that are currently >hosted on sourceforge fail to download due to some SSL errors (I've tested >this with the latest java sdk and ANT build). > >The AIR installer issue will require us to rip-and-replace the md5 >calculation functions. I've started looking at it, but I don't think it >will be an easy feat. >Fixing the ANT script for Windows trying to install the mac air dmg is an >easy fix (but it will require us to do a dot release to push it out) >The SSL errors are because sourceforge is using SANs on their SSL certs, >and the current versions of ANT don't know how to read them to validate >them. This may be out of our control. Anybody know if we can convince >Adobe to either donate those chunks of code or at least to move them to a >different host? It looks like the code involved is OSMF, AFE, AGLJ, >rideau and Flex-Fontkit. The alternative to a different host is for us to >ignore SSL errors, but that could be potentially dangerous. > >If nobody is working on these, I can start to take a crack at them, but >honestly, the installer is extremely fragile at this point and I'm not >looking forward to even trying to figure out what is going on in there >again. > >-Nick
