Maven 3.9.0-მა Resolver-ის ნაგულისხმევი HTTP transport Wagon-იდან native HTTP-ზე შეცვალა. ამიტომ ძველმა Wagon-ის workaround-მა შეიძლება repository-ის მოთხოვნების კონტროლი შეწყვიტოს, თუნდაც პროქსის URL არ შეცვლილიყო.

შეამოწმეთ გაშვებული Maven-ის ვერსია, settings.xml-ში არსებული აქტიური პროქსის კონფიგურაცია და არჩეული Resolver transport. ის, რომ JVM -D არგუმენტს იღებს, არ ამტკიცებს, რომ HTTP კლიენტი ამ property-ს იყენებს.

Maven 3.9-ის იმ რელიზებში, რომლებიც დოკუმენტირებულ selector-ს უჭერს მხარს, ეს შედარება Wagon-ს ითხოვს:

mvn -Dmaven.resolver.transport=wagon dependency:resolve

გაუშვით მხოლოდ მაშინ, როცა ნამდვილად გსურთ დამოკიდებულებების ჩამოტვირთვა იმავე პროექტისა და დამტკიცებული endpoint-ისთვის. ეს ქსელური ოპერაციაა და არა კონფიგურაციის მოთხოვნა. განსხვავებული შედეგი განხორციელების განსხვავებას ავიწროებს, მაგრამ Wagon-ს მუდმივ გადაწყვეტად არ აქცევს. Maven 4-თან ან მომავალ ვერსიასთან selector-ის გამოყენებამდე შეამოწმეთ მხარდაჭერილი სახელები.

ჩაიწერეთ რეალური challenge და შეცდომის ეტაპი. ბრაუზერის ავთენტიფიკაცია არ ამტკიცებს NTLM-ის მხარდაჭერას Maven-ის რომელიმე transport-ში. 407, სერტიფიკატის უარყოფა, მიუწვდომელი repository და timeout სხვადასხვა შესწორებას მოითხოვს. Pool-ის ან დროის პარამეტრების დამატებამდე, ან mirror-ებისა და artifact-ების ვერსიების შეცვლამდე, ჩაიწერეთ ვერსია, transport, პროქსის მეთოდი და ყველაზე მცირე გამეორებადი ოპერაცია. არჩეული გზისა და კონფიგურაციისთვის იხილეთ სასარგებლო დიაგნოსტიკური ანგარიში.

დაკავშირებული სტატიები