Кое поставување на прокси управува со преземањето на вашиот Maven wrapper?
Определете го bootstrap преземачот на wrapper-от пред да го конфигурирате проксито за неуспешно преземање на Maven дистрибуција.
Ако mvnw не успее додека го презема Maven, важечки прокси запис во settings.xml може да биде предоцна: Maven сè уште не е стартуван.
Прегледајте ги генерираните wrapper датотеки во погодената работна копија и утврдете кој преземач го извршуваат. Maven Wrapper 3.3.4 ги документира овие поставености:
| Генериран тип | Каде да се бара внесот за прокси |
|---|---|
| only-script | curl или wget на Unix; PowerShell на Windows |
| script | Преземањето на wrapper JAR, потоа патеката на Java wrapper |
| bin | Вклучениот wrapper JAR и неговата Java патека за преземање |
| source | Изворниот код на вклучениот Java преземач кога се користи за bootstrap |
only-script е документираното стандардно поставување за новогенерирани wrapper-и. Постара работна копија ги задржува своите генерирани датотеки, дури и ако ја ажурирате инсталацијата на Maven на вашата машина.
Усогласете го поставувањето со тој процес
За Unix only-script wrapper што користи curl или wget, конфигурирајте го прокси интерфејсот што го поддржува тој преземач; HTTPS преземање може да користи https_proxy. Ако тоа преземање на дистрибуцијата може да користи јавно HTTP прокси, земете кандидат адреса од списокот на HTTP прокси за околината на овој преземач. Ако вредноста наведува SOCKS сервер, преземачот мора да го поддржува и тој протокол.
MAVEN_OPTS обезбедува JVM опции. Тоа не може да го конфигурира curl процесот на школка, но JVM прокси својствата можат да бидат важни на Java патеката за преземање. Ова е корисната разлика кога се споредува старо Takari решение со wrapper на друг проект.
Кога преземањето на дистрибуцијата ќе заврши и Maven ќе стартува, неговите преземања од складиштата стануваат одделна проверка наспроти сопствената прокси конфигурација на Maven. Дистрибуцијата, wrapper JAR и складиштата може да ги служат различни домаќини.