On Mon, 13 Apr 2020 at 20:44, Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > Fetch the base updates.xml: ... > The difference is, that the "distibution" attributes are relative i the > base version and fully qualified in the mirror version. ... > Does this looks sane?
If you're thinking of generating every request for updates.xml? Not really?! The relative / base URL different in the XML can be a problem - eg. using the platform Ant scripts to create the platform will fail due to redirects maxing out downloading NBMs. I'm not sure if installing whole clusters in the IDE would trigger the same issue. In some ways we only redirect via NetBeans VM as a statistics gathering mechanism. It might be good if the IDE code followed redirects only for the updates.xml, and treated relative links as relative to the catalog endpoint anyway? I agree with Antonio that this is probably better handled in the end user's IDE itself. With Apache mirrors now moving to https, changing the update centre to directly reference a mirror may be the best short-term workaround - eg. https://www.mirrorservice.org/sites/ftp.apache.org/netbeans/netbeans/11.3/nbms/updates.xml.gz This obviously doesn't handle mirrors going away after next release is done - would need some logic to fall back to default on error if providing a UI for this? But we could add instructions for affected users to change UC links to mirrors in 12.0 and get reports back on issues before potentially progressing with UI in an update release? And in doing so deciding whether we need the statistics gathering aspect of this anyway. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
