Gradle proxy ayarlarını nereden alır

Gradle’ın JVM proxy özelliklerini, kullanıcı ana dizini ayarlarını ve istemci ortamını izleyin; daemonun yeni değişkenleri her zaman yok saydığını varsaymayın.

IDE’den başlatılan bir Gradle derlemesi, terminalden başlatılan aynı projeden farklı bir yapılandırma kullanabilir. Eski bir proxy sürecini suçlamadan önce her başlatmada kullanılan Gradle kullanıcı ana dizinini, JVM’yi ve proxy özelliklerini karşılaştırın.

Gradle JVM proxy özelliklerini belgeler

HTTP ve HTTPS yolları için bir özellikler dosyası şunları içerebilir:

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

Size atanan uç noktayı kullanın; izin verilen genel depo yolları için HTTP proxy listesi aday ana bilgisayar ve port çiftleri sağlar. HTTPS bypass özelliği de http.nonProxyHosts değeridir; https.nonProxyHosts uydurmak belgelenmiş çözüm değildir. Ana bilgisayar özellikleri tam bir proxy URL’si değil, bir adres içerir.

Bir kabukta HTTP_PROXY dışa aktarmak, bu JVM istemcisinin onu proxy politikası olarak kullandığını tek başına kanıtlamaz. Uygulamanın desteklediği özellikleri kontrol edin.

Daemon derleme bilgilerini gerçekten alır

Güncel Gradle belgeleri, istemcinin ortam değişkenleri de dahil derleme bilgilerini daemon’a gönderdiğini söyler. Bu nedenle “daemon yeni ortam değişkenlerini hiçbir zaman almaz” açıklaması genel olarak doğru değildir.

Güven deposu özellikleri gibi bazı JVM başlangıç özellikleri çalışan bir JVM için değiştirilemez. Bu yüzden normal derleme ortamı değerleri aktarılıyor olsa bile değiştirilmiş bir Java home veya güven deposu başlangıç yapılandırması önem taşıyabilir.

İki başlatmayı karşılaştırın

IDE’nin hangi Gradle dağıtımını ve Java çalışma zamanını seçtiğini kontrol edin. Terminalle aynı GRADLE_USER_HOME ve kullanıcı özelliklerini kullanıp kullanmadığını kontrol edin. Bir kullanıcının yapılandırmasındaki proxy girdisi başka bir bağlamın ne yüklediğini göstermez.

Değişen bir başlangıç gereksinimi farklı bir daemon gerektiriyorsa ilgili Gradle sürümü için belgelenmiş daemon denetimlerini kullanın. Daemonları durdurmayı yanlış bir özellik veya eksik yapılandırma dosyasını bulmanın yerine koymayın.

Son olarak başarısız olan isteği belirleyin. Wrapper indirmeleri, derleme bağımlılıklarının çözülmesi ve çatallanan uygulama veya test süreçlerinin yaptığı istekler otomatik olarak tek bir ağ bağlamı değildir. Bir Gradle özelliğinin onu denetlemesini beklemeden önce isteği yapan süreci doğrulayın.

İlgili makaleler