‏Maven חייב להגיע לתוסף ה-proxy לפני שהוא יכול להריץ אותו

תוסף proxy אוטומטי נשמע אידיאלי למחשב נייד שעובר בין רשתות. אבל יש בקשה ראשונה אחת מביכה: ייתכן ש-Maven זקוק ל-proxy כדי להשיג את התוסף עצמו.

יעד של תוסף פועל רק לאחר ש-Maven יכול לפתור ולטעון את המימוש שלו ואת הארטיפקטים הנדרשים. גילוי proxy בתוך אותו מימוש לא יכול לעזור להורדה שנכשלת לפני שהמימוש מתחיל. שימוש בקואורדינטות תוסף מלאות יכול להימנע מחיפוש לפי קידומת; אבל הוא לא גורם לארטיפקט התוסף להופיע במאגר מקומי ריק.

התוסף הישן Autoproxy של Maven ממחיש את ההבחנה. ה-README שלו מתאר גילוי proxy דרך proxy-vole, אך גם מתאר התקנה מקומית של התוסף לפני קריאה ליעד שלו. התייחסו לכך כתנאי מוקדם של אותו עיצוב מסוים, ולא כהוכחה ש-Maven קורא באופן אוניברסלי את הגדרות ה-PAC של הדפדפן.

תנו לפתרון הראשון מסלול מפורש

ברשת שבה הגישה למאגר דורשת proxy של HTTP, הגדירו את ה-proxy הפעיל המתאים בהגדרות Maven שבהן משמשת אותה קריאה. לאתחול מותר ממאגר ציבורי, בחרו מועמד HTTP מרשימת ה-proxy של HTTP. מאגר פנימי מאושר שנגיש ללא המסלול החיצוני יכול גם לפתור את בעיית הגישה הראשונית. כל גישה חייבת לכסות את התוסף ואת התלויות שלו, ולא רק את תלויות היישום.

מאגר מקומי שכבר אוכלס יכול להסתיר את דרישת האתחול. הצלחה במחשב הנייד של מפתח אינה מוכיחה שחשבון CI חדש יכול להתחיל את אותו build. הביטו בארטיפקט ובשלב שנכשלו לפני שתשנו את לוגיקת הזיהוי של התוסף.

לאחר שהתוסף נטען, כשל תלות מאוחר יותר הופך לשאלה נפרדת: האם המסלול שזוהה נכון והאם הובלת ה-Maven הפעילה משתמשת בהגדרות הנובעות מכך. שמרו על שני מוקדי הכשל הללו נפרדים כשאתם מחליטים אם זיהוי אוטומטי שווה להשאיר.