Репозиторії збірки сценаріїв для Android: jcenter VS mavencentral

Востаннє я використовував Android Studio, він генерував .gradleфайли з mavencentral()сховищами buildscript, тоді як зараз є jcenter().

Хтось може пояснити проблеми, пов’язані з цим. Чи є інші репости? Коли ми повинні переключити їх? Який вплив вони мають на проекти, модулі, наукові програми? Будь-які необхідні для розробників Android?

Хто відповідає за підтримку цих репостів?

У Bintray я просто повторив дуже детальну публікацію в блозі, де описав причини, через які Google вчинив цю зміну. Ось найважливіші моменти:

• JCenter - сховище Java в Bintray , яке є найбільшим репо в світі для бібліотек Java, Android та OSS OSS та їх компонентів.
• Весь вміст у JCenter подається через CDN із захищеним HTTPS-з'єднанням. Ще в часи міграції (Android Studio 0.8) Центральним сховищем maven 2 був лише HTTP, а HTTPS не підтримувався. Довідка: 51.6.2. Центральне сховище Мейвена .
• jcenter()є сукупністю mavenCentral(), що охоплює багато додаткових сховищ та артефактів.
• У різних сценаріях та в різних країнах Bintray швидше, ніж Maven Central (наприклад, з Ізраїлю). В інших це дуже близько. Оскільки Maven Central і Bintray використовують різні CDN, які адаптивно віддають перевагу регіонам, це може змінитись обома способами.
• Bintray має інший підхід до ідентифікації пакету, ніж спадщина Maven Central. Це велике і серйозне питання безпеки. Важливо.
• Якщо вам дійсно потрібно доставити пакунок до Maven Central (для підтримки застарілих інструментів), ви можете зробити це також від Bintray, одним натисканням кнопки або навіть автоматично .

Щодо покращення продуктивності, кілька прихильників розробників андроїд зіткнулися / помітили проблему величезної індексації з Maven central.

Словами Тор Норбі :

Я запустив AndroidStudio із абсолютно новим каталогом налаштувань, тому він підключив Maven Central та завантажив індекс доступних артефактів.

Тоді мені трапилось подивитися розмір мого каталогу.

Мій ~ / Бібліотека / Кеш / AndroidStudioPreview - це 1,5G, а 1,2G з них бере підкаталог "Maven".

Це смішно. Ми майже не використовуємо індекс. Основне використання для цього - це редактор Dependency в діалоговому вікні структури структури, але нам дійсно не потрібно мати попередньо обчислений індекс для цього. MavenCentral має швидкий онлайн-пошук JSON, який ми можемо використовувати на вимогу, коли хтось шукає артефакти. У https://android-review.googlesource.com/#/c/94843/ ми додали стрибкову перевірку, яка перевіряє, чи залежать сучасності, і пошук пригорщі артефактів майже миттєвий.

Словом, нам дійсно не потрібен кеш; це може допомогти у доопрацюванні коду у файлах .gradle та maven .pom, але це не надто важлива справа, і, звичайно, не те, що всі користувачі повинні пожертвувати 1,5 Г швидкості завантаження та дискового простору, щоб мати можливість один день робити. Читайте більше на тему: Індекс Maven величезний !

Крім того, вам може бути цікавим ця дуже коротка (1Q та 1A) дискусія про Hacker News .

^{Я з JFrog , компанією позадубінтрей і артефакторний, детальну інформацію та посилання див. у моєму профілі .}

Мені було цікаво те саме, і я не маю остаточної відповіді, але подумав, що, можливо, варто поділитися тим, що (мало) я дізнався. Я знайшов згадку про перехід від Maven Central до JCenter в одному випуску Google Code , але не зазначив деталей про те, коли саме це сталося - не вдалося згадати у списку останніх змін для Android Studio.

Почитавши JCenter, це сховище позаду Bintray, від компанії JFrog (з якою я зустрічався раніше, і я здогадуюсь, що звідки походить 'J'). Згідно з блогом Bintray, Bintray - це суперсеть Maven Central , тому, якщо це правда, не повинно виникнути проблем із відсутніми залежностями, але, мабуть, це буде залежати від того, що саме ви використовуєте у своїх проектах - ви завжди могли безпосередньо перевірте репост, оскільки обидва мають хороші веб-сайти, які легко шукати. Тож, хто підтримує ці репост, як я найкраще знаю, до виробників залежностей слід додати свої залежності до кожного репо, а до власника репо лише для підтримки сервісу.

З точки зору того, коли переключитися, складно відпрацювати. AOSP все ще використовує Maven Central, я думаю (від перегляду шаблонів для нового додатка Android), але потім для цього шаблону також використовується дуже стара версія Gradle (0.4). Існує кілька питань щодо інших, які мають проблеми із залежностями від jcenter, але насправді не так багато повідомляється, і можливо, Google перейде знову на якусь іншу репо перед тим, як випустити фінал AS. Якщо Maven Central поки що працює для вас добре, ви можете зупинити перемикання до тих пір, особливо якщо ви будуєте великі комерційні рішення.

Незалежно від того, що за замовчуванням знаходиться у файлі build.gradle - в командному проекті ви повинні реально використовувати диспетчер сховищ, наприклад Sonatype Nexus або JFrog Artifactory, а не посилатися безпосередньо на ці сховища вище.

Це дозволить вам зберегти велику пропускну здатність, об'єднати як і багато інших сховищ, так і керувати всім у власній мережі.

З точки зору Maven Central проти JCenter. JCenter намагається від JFrog прийняти, розширити (і винищити?) Maven Central. Maven Central - це сховище за замовчуванням у Maven, SBT та інших, тоді як Gradle перейшов на JCenter. Це не дивно, враховуючи, що JFrog та Gradleware працюють разом як компанії. Оскільки Android SDK використовує Gradle як систему збирання, перехід до JCenter був логічним наступним кроком.

Сам JCenter - це тонкий шпон на вершині Maven Central. Він надає йому проксі (більш-менш успішно) і додає додаткові компоненти. Обидва розміщені в мережах CDN та дуже ефективні. Сам Maven Central є ціллю для всіх Eclipse, Apache та більшості інших проектів з відкритим кодом, і без нього JCenter був би в основному порожнім.

Використання будь-якого з них спрацює нормально, але я б запропонував перейти безпосередньо до джерела, де ви можете, і поверх цього взяти на себе контроль за допомогою менеджера сховищ. Наприклад, Nexus Open Source є безкоштовним і підтримує сховища Maven, якими користуються Maven, Gradle, SBT, Ivy та інші, а також підтримку NuGet, NPM та RubyGems.

Відмова: Я є автором управління репозиторіями з Nexus і Nexus тренером для Sonatype, спонсором безкоштовного центрального сховища, керівником проекту плагіна Android Maven і підштовхнув деякі бібліотеки Android до Центрального за допомогою відновлення з AOSP.

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

Ця стаття може відповісти на ваше запитання.

Спочатку Android Studio вибрала Maven Central як сховище за замовчуванням. Після створення нового проекту зі старої версії Android Studio, mavenCentral () буде автоматично визначений у build.gradle.

Але велика проблема Maven Central полягає в тому, що це не сприятливо для розробників. На диво важко завантажити бібліотеку. Щоб мати змогу це зробити, розробник повинен бути на якомусь рівні видовищному стані. І маючи ще кілька причин, наприклад, питання безпеки та ін., Команда Android Studio вирішила замінити сховище за замовчуванням на jcenter замість того, як ви бачите, що після створення нового проекту з останньої версії Android Studio, jcenter () буде автоматично визначений замість mavenCentral ().