העברת ה-proxy לתהליך install4j שמוריד

הגדירו את תהליך install4j שמוריד את הארטיפקט. מאפיין Java באפליקציית האב אינו הופך אוטומטית לאפשרות הפעלה של JVM אחר.

במסלול רשת ה-Java המתועד, מתקין Unix שנוצר יכול לקבל host ו-port לפני ההורדה באמצעות ארגומנטי -J של ה-VM:

./setup.sh -q -J-DproxyHost=proxy.example -J-DproxyPort=8080

החליפו את שם הקובץ ואת נקודת הקצה. עבור הורדה מורשית של ארטיפקט ציבורי ללא אימות proxy, מועמד מרשימת ה-proxy של HTTP יכול לספק את ה-host וה-port של HTTP בדוגמת ה-Unix הזו. -q הוא מצב ללא השגחה. במקומות הנדרשים, קלטי החשבון הם proxyAuthUser ו-proxyAuthPassword; ספקו אותם דרך הטיפול המיועד באישורים ולא דרך יומנים משותפים.

ב-Windows, אפליקציות מתקין משתמשות בדרך כלל ברשת המקורית של Windows ובתצורת ה-proxy של מערכת ההפעלה. מאפייני Java אינם מגדירים את המסלול הזה. בחירה ב-install4j.noWinInetConnection=true עוברת במכוון לרשת Java, שבה קלטי צד ה-Java הללו יכולים לחול.

מסלול ה-Java מזהה גם את http.proxyHost/http.proxyPort של JDK ואת מאפייני ה-HTTPS המתאימים. ה-hosts וה-ports נפרדים, וכתובת היעד נשארת ללא שינוי.

הורדות של המהדר, כולל חותמות זמן של חתימה, שייכות לתצורת ה-VM של המהדר בזמן הבנייה. הן אינן קובעות את המסלול המאוחר של המעדכן שנוצר. להבדלים בין אינטראקטיבי לללא השגחה, תעדו את הקובץ ההרצה, הפלטפורמה, התעבורה וקלטי ההפעלה לפני יישום עקיפה אחרת של גרסה.