On 12/16/16, 10:11 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>On Fri, Dec 16, 2016 at 9:50 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 12/16/16, 6:22 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: >> >> >Hi, >> > >> >Looks like the CI build has finished and has produced artefacts: >> >http://apacheflexbuild.cloudapp.net:8080/job/flex- >> sdk_release-candidate/16 >> >6/artifact/out/ >> > >> >> I went to SourceForge and it looks like they've reorganized their >> >>download >> >> URLs so the one we are using may never work again. >> > >> >Perhaps it time to bundle them rather that try and keep fixing this >>every >> >time it breaks? Even we make the URL configurable one day (probably >>soon) >> >the downloads may not be available. >> >> I don't think we can bundle them in the source package. Won't the >>source >> build need to bring them down? The pattern we use for afe has been used >> to tweak the urls post-release many times already. >> > >I would say that the possibility of someone using an Installer and getting >the binary artifact is much higher than someone building the source >package. Sure, the source package build should attempt to download, but >it >would be better if we optimize the binary artifacts so that they are >easier >to use by the end users. I was hoping to avoid having to deal with changes to LICENSE and NOTICE and the installer. I think it would take much less community energy to just put in an Ant property for the new URL and call it done. We are at equal risk for changes to URLs for some dependencies we can't bundle. My 2 cents, -Alex