ਕਿਹੜੀ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਤੁਹਾਡੇ Maven wrapper ਡਾਊਨਲੋਡ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ?
ਅਸਫਲ Maven ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਡਾਊਨਲੋਡ ਲਈ ਪ੍ਰੌਕਸੀ ਸੰਰਚਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ wrapper ਦੇ bootstrap ਡਾਊਨਲੋਡਰ ਦੀ ਪਛਾਣ ਕਰੋ।
ਜੇ Maven ਡਾਊਨਲੋਡ ਕਰਦੇ ਸਮੇਂ mvnw ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ settings.xml ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਐਂਟਰੀ ਬਹੁਤ ਦੇਰ ਹੋ ਸਕਦੀ ਹੈ: Maven ਅਜੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ।
ਪ੍ਰਭਾਵਿਤ checkout ਵਿੱਚ ਬਣੀਆਂ wrapper ਫਾਈਲਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਪਛਾਣੋ ਕਿ ਉਹ ਕਿਹੜਾ ਡਾਊਨਲੋਡਰ ਚਲਾਉਂਦੀਆਂ ਹਨ। Maven Wrapper 3.3.4 ਇਹਨਾਂ ਪ੍ਰਬੰਧਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ:
| ਬਣਾਇਆ ਗਿਆ ਕਿਸਮ | ਪ੍ਰੌਕਸੀ ਇਨਪੁਟ ਕਿੱਥੇ ਲੱਭਣਾ ਹੈ |
|---|---|
| only-script | Unix 'ਤੇ curl ਜਾਂ wget; Windows 'ਤੇ PowerShell |
| script | wrapper JAR ਦਾ ਡਾਊਨਲੋਡ, ਫਿਰ Java wrapper ਪਾਥ |
| bin | ਸ਼ਾਮਲ wrapper JAR ਅਤੇ ਇਸਦਾ Java ਡਾਊਨਲੋਡ ਪਾਥ |
| source | bootstrap ਲਈ ਵਰਤੇ ਜਾਣ 'ਤੇ ਸ਼ਾਮਲ Java ਡਾਊਨਲੋਡਰ ਦਾ ਸਰੋਤ |
only-script ਨਵੇਂ ਬਣਾਏ wrapper ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਡਿਫਾਲਟ ਹੈ। ਪੁਰਾਣਾ checkout ਆਪਣੀਆਂ ਬਣਾਈਆਂ ਫਾਈਲਾਂ ਰੱਖਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ Maven ਇੰਸਟਾਲੇਸ਼ਨ ਅੱਪਡੇਟ ਕਰੋ।
ਸੈਟਿੰਗ ਨੂੰ ਉਸ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਮਿਲਾਓ
curl ਜਾਂ wget ਵਰਤਣ ਵਾਲੇ Unix only-script wrapper ਲਈ, ਉਸ ਡਾਊਨਲੋਡਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਪ੍ਰੌਕਸੀ ਇੰਟਰਫੇਸ ਸੰਰਚਿਤ ਕਰੋ; HTTPS ਡਾਊਨਲੋਡ https_proxy ਵਰਤ ਸਕਦਾ ਹੈ। ਜੇ ਉਹ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਡਾਊਨਲੋਡ ਜਨਤਕ HTTP ਪ੍ਰੌਕਸੀ ਵਰਤ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸ ਡਾਊਨਲੋਡਰ ਦੇ ਵਾਤਾਵਰਣ ਲਈ HTTP ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਤੋਂ ਇੱਕ ਉਮੀਦਵਾਰ ਪਤਾ ਲਓ। ਜੇ ਮੁੱਲ SOCKS ਸਰਵਰ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਡਾਊਨਲੋਡਰ ਨੂੰ ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਸਮਰਥਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
MAVEN_OPTS JVM ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ। ਇਹ shell ਦੀ curl ਪ੍ਰਕਿਰਿਆ ਸੰਰਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪਰ JVM ਪ੍ਰੌਕਸੀ ਗੁਣ Java ਡਾਊਨਲੋਡਰ ਪਾਥ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੇ ਹਨ। ਪੁਰਾਣੇ Takari ਹੱਲ ਦੀ ਦੂਜੇ ਪ੍ਰੋਜੈਕਟ ਦੇ wrapper ਨਾਲ ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ ਇਹ ਲਾਹੇਵੰਦ ਅੰਤਰ ਹੈ।
ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਡਾਊਨਲੋਡ ਪੂਰਾ ਹੋਣ ਅਤੇ Maven ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਸਦੇ ਰਿਪੋਜ਼ਟਰੀ ਡਾਊਨਲੋਡ Maven ਦੀ ਆਪਣੀ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਵੱਖਰੀ ਜਾਂਚ ਬਣ ਜਾਂਦੇ ਹਨ। ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ, wrapper JAR ਅਤੇ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵੱਖ-ਵੱਖ ਹੋਸਟਾਂ ਦੁਆਰਾ ਪਰੋਸੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।