> El 30 oct 2017, a las 18:35, Matthias Bläsing <[email protected]> > escribió: > > Hey, > > Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach: >> 2017-10-25 6:21 GMT+02:00 Antonio Vieiro <[email protected]>: >> >>> >>> I was wondering we could upgrade the “download task” in nbbuild to >>> automatically select binary versions for eclipse binaries, so, for >>> instance, our binaries-list could be something like: >>> >>> eclipse://4.7/org.eclipse.core.jobs >>> >>> And leave the responsibility of choosing (verifying) an appropriate >>> version of “org.eclipse.core.jobs” to the download task. >>> >> >> I was thinking about adding List<String> repositories; attribute into the >> download task and then configure it to list as many Maven repositories as >> possible. The download would then try them one by one as regular Maven >> does. Then default.xml or some other file would register all the Maven >> repositories we need for the build. This should solve our issues >> temporarily. > > I think this idea is sound and it would be direction I would take. I > would not add complexity by adding a repository prefix.
I’ll add this to PR#204. Let’s get this done ASAP. Later on we can fine-tune the downloads mechanism, using some sort of parallelization to speed things up. > >> On the other hand during review of HTML/Java API I had to remove download >> from google Maven repository - it was seen as untrusted. I assume the same >> will be said about the eclipse repository. > > I don't follow that argument. The trust basis is the SHA1 hash that is > checked at download time. At this point in time I consider SHA1 as a > save basis and thus I don't care if the binary comes from maven centra, > the eclipse repository or whatever. Untrusted because missing https certificates, maybe? The DownloadBinaries.java ant task currently uses plain http, so no worries about https certificates (but we could use a custom SSLSocketFactory with some certs if required). Cheers, Antonio
