Каково правило каталога кода sha1 в пути кэширования gradle?

Question

Я хочу скачать jar из сети и добавить его в кеш gradle (.gradle / caches / modules-2 / files-2.1), но я не знаю, как сгенерировать его каталог SHA1.

И я узнал из сети, знал, что код SHA1 был сгенерирован URL-адресом jar (т. Е. http://4thline.org/m2/org/fourthline/cling/cling-core/2.1.1/cling-core-2.1.1.jar),, а каталог SHA1 - это код SHA1 URL-адреса, но это неверно, когда я его проверил. Поэтому яхочу выяснить, что это за правило.

Например, код SHA1 этого URL (http://4thline.org/m2/org/fourthline/cling/cling-core/2.1.1/cling-core-2.1.1.jar) равен c68bd953b6f2b0b7022a3ca26afeb6ecd40dbeef, но код SHA1, сгенерированный Gradle, равен 767954a4d738b8c77606d19a6c0255193651ccba.не то же самое.

Проверьте эти фотографии

НаконецНадеюсь, вы, ребята, можете предоставить полезную информацию, пожалуйста. Спасибо!

Answer 1

Вы не должны пытаться сделать это, пока он будет работать, , если все сделано правильно , для кэша file, он не будет работать для кэша метаданных.

И посколькуGradle стремится к воспроизводимой сборке, вы сохраните только загрузку файла, а не тот факт, что сборка Gradle должна определить хранилище, где файл может быть найден и где запрос HEAD подтвердит егоSHA1.

Answer 2

Вы сравниваете SHA файла с SHA URL.Ша, которую вы рассматриваете с gradle, это ша URL, с которого загружается баночка.gradle поддерживает sha url для кэширования и избегает многократных загрузок jar в dependency tree.Как вы знаете, sha будет уникальным, поэтому существующий jar-файл зависимостей никогда не загрузится снова, пока вы не измените саму зависимость.Там, где файл sha является своего рода подписью, чтобы гарантировать, что содержимое файла не изменено, и это как есть.Надеюсь, теперь все ясно.