Android buildscript depoları: jcenter VS mavencentral

Android Studio'yu en son kullandığımda , şimdi buildscript havuzlarıyla .gradledosyalar mavencentral()üretti jcenter().

Herkes bununla ilgili sorunları açıklayabilir. Başka depo var mı? Ne zaman değiştirmeliyiz? Projeler, modüller, kütüphaneler üzerinde ne gibi etkileri var? Android geliştiricileri için başka herhangi bir gereklilik var mı?

Bu depoları korumaktan kim sorumlu?

Bintray'de , Google'ın bu değişikliği yapmasının nedenlerini açıklayan çok ayrıntılı bir blog gönderisini yeniden bloke ettim . İşte en önemli noktalar:

• JCenter, Bintray'de Java ve Android OSS kütüphaneleri, paketleri ve bileşenleri için dünyanın en büyük deposu olan bir Java deposudur .
• JCenter'daki tüm içerik güvenli bir HTTPS bağlantısı olan bir CDN üzerinden sunulur. Geçiş zamanında (Android Studio 0.8) Merkezi maven 2 deposu yalnızca HTTP'ydi ve HTTPS desteklenmiyordu. Referans: 51.6.2. Maven merkez deposu .
• jcenter()mavenCentral()birçok ek havuzu ve yapay nesneyi kapsayan bir üst kümedir .
• Farklı senaryolarda ve farklı ülkelerden Bintray Maven Central'dan (örneğin İsrail'den) daha hızlıdır. Diğerlerinde ise çok yakın. Maven Central ve Bintray, bölgeleri uyarlamalı olarak destekleyen farklı CDN'ler kullandığından, bu her iki yönde de değişebilir.
• Bintray, paket tanımlama konusunda eski Maven Central'dan farklı bir yaklaşıma sahiptir. Bu büyük ve ciddi bir güvenlik meselesidir. Bu önemli.
• Paketinizi gerçekten Maven Central'a (eski araçları desteklemek için) götürmeniz gerekiyorsa, Bintray'den , bir düğmeye tıklayarak veya hatta otomatik olarak yapabilirsiniz .

Performans geliştirmeleri ile ilgili olarak, birkaç android geliştirici savunucusu maven merkezi ile büyük endeksleme sorunuyla karşı karşıya kaldı / fark etti.

Tor Norbye'nin sözleriyle :

AndroidStudio'yu yepyeni bir ayarlar dizini ile çalıştırdım, bu yüzden gitti ve maven merkezini bağladı ve mevcut eserlerin bir dizinini indirdi.

Sonra dizinimin boyutuna baktım.

~ / Library / Cache / AndroidStudio'um Önizleme 1.5G ve bunların 1.2G'si “Maven” alt dizini tarafından alındı.

Saçma. Dizini neredeyse hiç kullanmıyoruz. Bunun birincil kullanımı Proje Yapısı İletişim Kutusunda Bağımlılık düzenleyicisidir, ancak bunun için önceden hesaplanmış bir dizine sahip olmamız gerekmez. MavenCentral, birileri yapay nesneler ararken talep üzerine kullanabileceğimiz hızlı bir çevrimiçi JSON aramasına sahiptir. Gelen https://android-review.googlesource.com/#/c/94843/ biz bağımlılıkları olmadığını denetler güncel bir tiftik çek eklendi ve eserler bir avuç arayışı neredeyse anlık olduğunu.

Kısacası, gerçekten önbelleğe ihtiyacımız yok; .gradle ve maven .pom dosyalarında kod tamamlanmasına yardımcı olabilir, ancak bu çok önemli bir kullanıcı tabanı değildir ve kesinlikle tüm kullanıcıların bir gün yapabilme olasılığı için 1.5G indirme hızını ve disk alanını feda etmesi gereken bir şey değildir . Daha fazla bilgi için: Maven endeksi çok büyük !

Ayrıca, Hacker News hakkındaki bu çok kısa (1Q ve 1A) tartışmayı ilginç bulabilirsiniz.

^{Arkasındaki şirket JFrog ile birlikteyimbintray ve artifactory, profilime bak ayrıntılar ve bağlantılar için .}

Ben de aynı şeyi merak ediyordum ve kesin bir cevabım yok ama öğrendiğimi (az) paylaşmaya değeceğini düşündüm. Google Code'daki bir sayı içinde Maven Central'dan JCenter'a geçişten bahsettim , ancak tam olarak ne zaman gerçekleştiğine dair ayrıntıları tespit etmedim - Android Studio için son değişiklikler listesinde bahsedilemedi.

JCenter'de okumadan, JFrog şirketinden (daha önce karşılaştığım Bintray'ın arkasındaki depo ve sanırım 'J' nereden geliyor). Bintray bloguna göre, Bintray Maven Central'ın bir üst kümesidir , bu yüzden eğer doğruysa eksik bağımlılıklarla ilgili sorunlar olmamalıdır, ancak sanırım bu projelerinizde tam olarak ne kullandığınıza bağlı olacaktır - her zaman doğrudan her ikisi de kolayca aranabilir web siteleri var gibi depoları kontrol edin. Bu depoları kimin koruduğu için, en iyi bildiğim kadarıyla, bağımlılıkları üreticilerin her bir repoya bağımlılıklarını eklemek ve sadece hizmeti korumak için repo sahibine kadar.

Ne zaman değiştirileceği açısından çalışmak zordur. AOSP hala Maven Central'ı kullanıyor (Sanırım Yeni Android Uygulaması için Şablonlar'a bakarken), ancak bu şablon da hala çok eski bir Gradle sürümü (0.4) kullanıyor. Diğerleri hakkında jcenter bağımlılıkları ile ilgili sorunları olan, ancak gerçekten çok fazla rapor edilmeyen birkaç sorun var ve Google, AS finalini yayınlamadan önce tekrar başka bir repoya geçecek. Maven Central şimdilik sizin için iyi çalışıyorsa, özellikle büyük ticari çözümler geliştiriyorsanız o zamana kadar geçişi durdurabilirsiniz.

Build.gradle dosyasındaki varsayılan değer ne olursa olsun - ekip tabanlı bir geliştirme çabasında Sonatype Nexus veya JFrog Artifactory gibi bir depo yöneticisini kullanmalı ve doğrudan bu yukarı doğru depolara başvurmamalısınız.

Bu, çok fazla bant genişliği kaydetmenize, hem de diğer birçok depoları birleştirmenize ve hepsini kendi ağınızda yönetmenize izin verecektir.

Maven Central vs JCenter açısından. JCenter, JFrog'dan Maven Central'ı benimseme, genişletme (ve yok etme?) Çabasıdır. Maven Central, Maven, SBT ve diğerlerinde varsayılan depo, Gradle ise JCenter'a geçti. JFrog ve Gradleware'in şirketler olarak birlikte çalıştığı düşünüldüğünde bu şaşırtıcı değil. Android SDK, Gradle'ı derleme sistemi olarak kullandığından, JCenter'a geçiş bir sonraki adımdı.

JCenter'in kendisi Maven Central'ın tepesinde ince bir kaplamadır. Proxy yapar (az çok başarılı bir şekilde) ve ek bileşenler ekler. Her ikisi de CDN ağlarında barındırılır ve yüksek performans gösterir. Maven Central'ın kendisi tüm Eclipse, Apache ve diğer birçok açık kaynaklı projenin hedefidir ve onsuz JCenter çoğunlukla boş olurdu.

Bunlardan birini kullanmak iyi çalışacaktır, ancak doğrudan kaynağa gitmenizi öneririm ve bunun üzerine bir havuz yöneticisi kullanarak bunun kontrolünü ele geçiririm. Örneğin Nexus Açık Kaynak ücretsizdir ve Maven, Gradle, SBT, Ivy ve diğerleri tarafından kullanılan Maven depolarına ve NuGet, NPM ve RubyGems desteğine sahiptir.

Feragatname: Android Central Maven Plugin'in proje lideri Sonatype için Nexus ve Nexus eğitmeni ile Repository Management'ın yazarı ve AOSP'dan yeniden inşa ederek bazı Android kütüphanelerini Central'a ittim.

http://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en

bu makale size cevap verebilir.

İlk başta, Android Studio varsayılan bir depo olarak Maven Central'ı seçti. Android Studio'nun eski sürümünden yeni bir proje oluşturduğunuzda, mavenCentral () otomatik olarak build.gradle içinde tanımlanır.

Ancak Maven Central'ın en büyük problemi geliştirici dostu olmaması. Kütüphaneyi yüklemek şaşırtıcı derecede zor. Bunu yapabilmek için geliştiricinin bir miktar geeky seviyesinde olması gerekir. Örneğin, bir güvenlik endişesi ve benzeri başka bir nedenle, Android Studio ekibi varsayılan depoyu jcenter'a değiştirmeye karar verdi, çünkü Android Studio'nun en son sürümünden yeni bir proje oluşturduktan sonra jcenter () otomatik olarak tanımlanacak mavenCentral () yerine.