ავტომატური proxy-პლაგინი იდეალური ჩანს ლეპტოპისთვის, რომელიც ქსელებს შორის გადაადგილდება. თუმცა ერთი უხერხული პირველი მოთხოვნა არსებობს: შესაძლოა Maven-ს proxy სჭირდებოდეს თავად პლაგინის მისაღებად.

პლაგინის მიზანი სრულდება მხოლოდ მას შემდეგ, რაც Maven შეძლებს მისი იმპლემენტაციისა და საჭირო არტეფაქტების გადაწყვეტასა და ჩატვირთვას. proxy-ს აღმოჩენა ამ იმპლემენტაციის შიგნით ვერ დაეხმარება ჩამოტვირთვას, რომელიც იმპლემენტაციის დაწყებამდე ვარდება. სრულად კვალიფიციური პლაგინის კოორდინატების გამოყენებამ შეიძლება თავიდან აიცილოს პრეფიქსური ძიება; მაგრამ ის არ აჩენს პლაგინის არტეფაქტს ცარიელ ლოკალურ რეპოზიტორში.

ძველი Autoproxy Maven პლაგინი აჩვენებს ამ განსხვავებას. მისი README აღწერს proxy-ს აღმოჩენას proxy-vole-ის მეშვეობით, მაგრამ ასევე აღწერს პლაგინის ლოკალურ ინსტალაციას მისი მიზნის გამოძახებამდე. მიიჩნიეთ ეს იმ კონკრეტული დიზაინის წინაპირობად და არა მტკიცებად, რომ Maven უნივერსალურად კითხულობს ბრაუზერის PAC პარამეტრებს.

მიეცით პირველ გადაწყვეტას ცხადი მარშრუტი

ქსელისთვის, სადაც რეპოზიტორზე წვდომა HTTP proxy-ს მოითხოვს, დააკონფიგურირეთ შესაბამისი აქტიური proxy Maven პარამეტრებში, რომლებსაც ეს გამოძახება იყენებს. დაშვებული საჯარო რეპოზიტორიდან ჩატვირთვისთვის აირჩიეთ HTTP კანდიდატი HTTP proxy-ების სიიდან. დამტკიცებულ შიდა რეპოზიტორს, რომელიც გარე მარშრუტის გარეშე ხელმისაწვდომია, ასევე შეუძლია საწყისი წვდომის პრობლემის გადაჭრა. ნებისმიერმა მიდგომამ უნდა დაფაროს პლაგინი და მისი დამოკიდებულებები, და არა მხოლოდ აპლიკაციის დამოკიდებულებები.

ადრე შევსებულმა ლოკალურმა რეპოზიტორმა შეიძლება დამალოს ჩატვირთვის მოთხოვნა. წარმატება დეველოპერის ლეპტოპზე არ ამტკიცებს, რომ ახალ CI ანგარიშს შეუძლია იმავე აწყობის დაწყება. შეხედეთ წარუმატებელ არტეფაქტსა და ფაზას, სანამ პლაგინის აღმოჩენის ლოგიკას შეცვლით.

პლაგინის ჩატვირთვის შემდეგ, მოგვიანო დამოკიდებულების ჩავარდნა ცალკე კითხვად იქცევა: სწორია თუ არა აღმოჩენილი მარშრუტი და იყენებს თუ არა აქტიური Maven ტრანსპორტი მიღებულ პარამეტრებს. ეს ორი ჩავარდნის წერტილი ცალ-ცალკე შეინახეთ, როცა გადაწყვეტთ, ღირს თუ არა ავტომატური აღმოჩენის შენარჩუნება.

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