Repozytoria buildscript dla Androida: jcenter VS mavencentral

Kiedy ostatnio korzystałem z Android Studio, generowałem .gradlepliki z mavencentral()repozytoriami buildscript, ale teraz jest jcenter().

Czy ktoś mógłby wyjaśnić związane z tym problemy. Czy są jeszcze jakieś repozytoria? Kiedy powinniśmy je zamienić? Jaki wpływ mają na projekty, moduły, biblioteki? Jakieś inne niezbędne rzeczy dla programistów Androida?

Kto jest odpowiedzialny za utrzymanie tych repozytoriów?

Na Bintray właśnie opublikowałem bardzo szczegółowy post na blogu opisujący powody, dla których Google dokonało tej zmiany. Oto najważniejsze punkty:

• JCenter to repozytorium Java w Bintray , które jest największym na świecie repozytorium dla bibliotek, pakietów i komponentów OSS Java i Android.
• Cała zawartość w JCenter jest obsługiwana przez CDN, z bezpiecznym połączeniem HTTPS. W czasie migracji (Android Studio 0.8) Centralne repozytorium maven 2 było tylko HTTP i HTTPS nie był obsługiwany. Odniesienie: 51.6.2. Centralne repozytorium Maven .
• jcenter()jest nadzbiorem mavenCentral(), który obejmuje wiele dodatkowych repozytoriów i artefaktów.
• W różnych scenariuszach iz różnych krajów Bintray jest szybszy niż Maven Central (np. Z Izraela). W innych jest bardzo blisko. Ponieważ Maven Central i Bintray używają różnych sieci CDN, które adaptacyjnie faworyzują regiony, może to zmienić się na dwa sposoby.
• Bintray ma inne podejście do identyfikacji paczek niż starsze Maven Central. To duża i poważna kwestia bezpieczeństwa. To jest ważne.
• Jeśli naprawdę potrzebujesz dostarczyć paczkę do Maven Central (w celu obsługi starszych narzędzi), możesz to zrobić również z Bintray, jednym kliknięciem przycisku lub nawet automatycznie .

Jeśli chodzi o poprawę wydajności, kilku zwolenników programistów Androida napotkało / zauważyło problem ogromnego indeksowania za pomocą maven central.

Słowami Tor Norbye :

Uruchomiłem AndroidStudio z zupełnie nowym katalogiem ustawień, więc połączyłem maven central i pobrałem indeks dostępnych artefaktów.

Potem zdarzyło mi się spojrzeć na rozmiar mojego katalogu.

Mój ~ / Library / Cache / AndroidStudioPreview ma 1,5G, a 1,2G z nich znajduje się w podkatalogu „Maven”.

To niedorzeczne. W ogóle nie korzystamy z indeksu. Podstawowym zastosowaniem jest edytor zależności w oknie dialogowym Struktura projektu, ale tak naprawdę nie potrzebujemy dla niego wstępnie obliczonego indeksu. MavenCentral ma szybkie wyszukiwanie JSON online, z którego możemy korzystać na żądanie, gdy ktoś szuka artefaktów. W https://android-review.googlesource.com/#/c/94843/ dodaliśmy kontrolę kłaczków, która sprawdza, czy zależności są aktualne, a poszukiwanie kilku artefaktów jest prawie natychmiastowe.

Krótko mówiąc, naprawdę nie potrzebujemy bufora; może to pomóc w uzupełnianiu kodu w plikach .gradle i maven .pom, ale nie jest to bardzo ważny przypadek użycia, a na pewno nie jest to coś, co wszyscy użytkownicy powinni poświęcić 1,5G prędkości pobierania i miejsca na dysku, aby mieć możliwość zrobienia jednego dnia. Czytaj więcej na: Indeks Maven jest ogromny !

Również ta krótka (1Q i 1A) dyskusja w Hacker News może okazać się interesująca.

^{Jestem z JFrog , firmą z tyłubintray i sztuczny, zobacz mój profil po szczegóły i linki.}

Zastanawiałem się nad tym samym i nie mam ostatecznej odpowiedzi, ale pomyślałem, że warto podzielić się tym, czego (niewiele) się nauczyłem. Znalazłem wzmiankę o przejściu z Maven Central do JCenter w ramach jednego numeru Google Code , ale nie dostrzegłem szczegółów dokładnie, kiedy to się stało - nie mogłem znaleźć wzmianki na liście ostatnich zmian dla Androida Studio.

Po przeczytaniu na JCenter, jest to repozytorium za Bintray, od firmy JFrog (z którą się wcześniej spotkałem i chyba stąd pochodzi „J”). Według bloga Bintray Bintray jest nadzbiorem Maven Central , więc jeśli to prawda, nie powinno być problemów z brakującymi zależnościami, ale myślę, że będzie to zależało od tego, czego dokładnie używasz w swoich projektach - zawsze możesz bezpośrednio sprawdź repozytorium, ponieważ oba mają ładne, łatwe do przeszukiwania strony internetowe. Więc dla tych, którzy utrzymują te repozytoria, jak najlepiej wiem, od producentów zależności zależy, czy dodadzą swoje zależności do każdego repozytorium, a od właściciela repozytorium po prostu utrzymanie usługi.

Trudno jest się zorientować, kiedy zmienić. Myślę, że AOSP nadal korzysta z Maven Central (po przejrzeniu szablonów dla nowej aplikacji na Androida), ale potem ten szablon również używa bardzo starej wersji Gradle (0.4). Jest kilka problemów z innymi, którzy mają problemy z zależnościami od jcenter, ale nie jest to zbyt wiele zgłaszanych, i możliwe jest, że Google ponownie przełączy się na inne repo przed wydaniem AS final. Jeśli Maven Central nadal działa dla ciebie dobrze, możesz wstrzymać się z przełączaniem do tego czasu, szczególnie jeśli budujesz duże rozwiązania komercyjne.

Bez względu na domyślną wartość w pliku build.gradle - w zespołowym wysiłku programistycznym powinieneś naprawdę użyć menedżera repozytorium, takiego jak Sonatype Nexus lub JFrog Artifactory i nie odwoływać się bezpośrednio do tych repozytoriów.

Pozwoli ci to zaoszczędzić dużo przepustowości, połączyć oba i wiele innych repozytoriów oraz zarządzać nimi we własnej sieci.

Pod względem Maven Central vs. JCenter. JCenter to wysiłek JFrog, aby objąć, rozszerzyć (i eksterminować?) Maven Central. Maven Central jest domyślnym repozytorium w Maven, SBT i innych, podczas gdy Gradle przeszedł na JCenter. Nie jest to zaskakujące, biorąc pod uwagę, że JFrog i Gradleware współpracują ze sobą jako firmy. Ponieważ zestaw Android SDK używa teraz Gradle jako systemu kompilacji, przejście do JCenter było logicznym krokiem.

Sam JCenter to cienki fornir na wierzchu Maven Central. Przybliża go (mniej lub bardziej skutecznie) i dodaje dodatkowe komponenty. Oba są hostowane w sieciach CDN i charakteryzują się wysoką wydajnością. Sam Maven Central jest celem wszystkich projektów Eclipse, Apache i większości innych projektów open source, a bez niego JCenter byłby w większości pusty.

Używanie któregokolwiek z nich będzie działało dobrze, ale sugerowałbym, aby przejść bezpośrednio do źródła, w którym możesz, a ponadto przejąć nad nim kontrolę za pomocą menedżera repozytorium. Nexus Open Source na przykład jest bezpłatny i ma obsługę repozytoriów Maven używanych przez Maven, Gradle, SBT, Ivy i innych, a także obsługę NuGet, NPM i RubyGems.

Oświadczenie: Jestem autorem Repository Management with Nexus i trenerem Nexus dla Sonatype, sponsora bezpłatnego Central Repository, lidera projektu wtyczki Android Maven i przesunąłem niektóre biblioteki Androida do Central poprzez przebudowę z AOSP.

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

ten artykuł może odpowiedzieć na pytanie.

Początkowo Android Studio wybrało Maven Central jako domyślne repozytorium. Po utworzeniu nowego projektu ze starej wersji Androida Studio mavenCentral () zostanie automatycznie zdefiniowany w build.gradle.

Ale głównym problemem Maven Central jest to, że nie jest przyjazny dla programistów. Zaskakująco trudno jest wgrać bibliotekę do. Aby móc to zrobić, programista musi być na pewnym poziomie naukowy. I z nieco innych powodów, na przykład dotyczących bezpieczeństwa itp., Zespół Android Studio postanowił zamiast tego zmienić domyślne repozytorium na jcenter, ponieważ widać, że po utworzeniu nowego projektu z najnowszej wersji Androida Studio, jcenter () zostanie automatycznie zdefiniowane zamiast mavenCentral ().