Репозитории Android buildscript: jcenter ПРОТИВ mavencentral
В прошлый раз, когда я использовал Android Studio, он генерировал .gradle
файлы с mavencentral()
репозиториями buildscript, тогда как теперь есть jcenter()
.
Кто-нибудь может объяснить проблемы, связанные с этим. Существуют ли какие-либо другие репозитории? Когда мы должны их переключать? Какое влияние они оказывают на проекты, модули, библиотеки? Любые другие основы для разработчиков Android?
Кто отвечает за обслуживание этих репозиториев?
Переведено автоматически
Ответ 1
В Bintray я только что обновил очень подробный пост в блоге, описывающий причины, по которым Google внес это изменение. Вот наиболее важные моменты:
- JCenter - это репозиторий Java в Bintray, который является крупнейшим репозиторием в мире для библиотек, пакетов и компонентов операционных систем Java и Android.
- Все содержимое в JCenter передается по CDN с безопасным HTTPS-соединением. Во времена миграции (Android Studio 0.8) Центральный репозиторий maven 2 работал только по HTTP, а HTTPS не поддерживался. Ссылка: 51.6.2. Центральный репозиторий Maven.
jcenter()
это надмножествоmavenCentral()
, которое включает в себя множество дополнительных репозиториев и артефактов.- В разных сценариях и из разных стран Bintray работает быстрее, чем Maven Central (например, из Израиля). В других случаях он очень близок. Поскольку Maven Central и Bintray используют разные CDN, которые адаптивно поддерживают регионы, это может измениться в обе стороны.
- В Bintray используется иной подход к идентификации пакетов, чем в устаревшем Maven Central. Это большой и серьезный вопрос безопасности. Это важно.
- Если вам действительно нужно отправить свой пакет в Maven Central (для поддержки устаревших инструментов), вы также можете сделать это из Bintray, одним нажатием кнопки или даже автоматически.
Что касается улучшения производительности, пара сторонников разработчиков Android столкнулись / заметили проблему огромной индексации с maven central.
По словам Tor Norbye:
Я запустил AndroidStudio с совершенно новым каталогом настроек, поэтому он подключил maven central и загрузил индекс доступных артефактов.
Затем я случайно посмотрел на размер своего каталога.
Размер моего ~/Library / Cache / AndroidStudioPreview составляет 1,5 Гб, из которых 1,2 Гб занимает подкаталог “Maven”.
Это смешно. Мы вообще почти не используем индекс. В основном он используется в редакторе зависимостей в диалоговом окне Структуры проекта, но нам действительно не нужен предварительно вычисленный индекс для него. В MavenCentral есть быстрый онлайн-поиск в формате JSON, который мы можем использовать по запросу, когда кто-то ищет артефакты. В https://android-review.googlesource.com/#/c/94843 / мы добавили проверку lint, которая проверяет актуальность зависимостей, и поиск нескольких артефактов происходит практически мгновенно.
Короче говоря, нам действительно не нужен кеш; это может помочь с завершением кода в файлах .gradle и maven .pom, но это не очень важная область использования, и, конечно, не то, что все пользователи должны жертвовать 1,5 гигабайтами скорости загрузки и дискового пространства, чтобы иметь возможность сделать в один прекрасный день. Читайте дальше: Индекс Maven огромен!
Кроме того, вам может показаться очень короткой (1 квартал и 1А) дискуссия на Hacker News интересной.
Я из JFrog, компании, стоящей за bintray и artifactory, смотрите мой профиль для получения подробной информации и ссылок.
Ответ 2
Мне было интересно то же самое, и у меня нет окончательного ответа, но решила, что стоит поделиться тем, что (мало) Я бы узнал. Я нашел упоминание о переходе с Maven Central на JCenter в одном выпуске Google Code, но не обнаружил подробностей о том, когда именно это произошло - не удалось найти упоминание в списке последних изменений для Android Studio.
Судя по JCenter, это репозиторий, стоящий за Bintray, от компании JFrog (с которой я сталкивался раньше, и я предполагаю, что именно оттуда происходит "J"). Согласно блогу Bintray, Bintray является надмножеством Maven Central, поэтому, если это правда, проблем с отсутствующими зависимостями быть не должно, но я предполагаю, что это будет зависеть от того, что именно вы используете в своих проектах - вы всегда можете напрямую проверить репозитории, поскольку у обоих есть хорошие веб-сайты с удобным поиском. Итак, кто обслуживает эти репозитории, насколько я знаю, производители зависимостей должны добавлять свои зависимости к каждому репозиторию, а владелец репозитория - просто поддерживать службу.
С точки зрения того, когда переключаться, разобраться сложно. Я думаю, что AOSP все еще использует Maven Central (из поиска шаблонов для нового приложения Android), но тогда этот шаблон также все еще использует очень старую версию Gradle (0.4). Есть пара вопросов о том, что у других есть проблемы с зависимостями от jcenter, но на самом деле сообщений не так много, и возможно, что Google снова переключится на какой-нибудь другой репозиторий, прежде чем выпустить его КАК окончательный. Если Maven Central все еще работает у вас нормально, вы могли бы отложить переключение до тех пор, особенно если вы создаете крупные коммерческие решения.
Ответ 3
Независимо от значения по умолчанию в файле 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 с открытым исходным кодом бесплатен и поддерживает репозитории Maven, используемые Maven, Gradle, SBT, Ivy и другими, а также NuGet, NPM и RubyGems.
Отказ от ответственности: Я являюсь автором книги " Управление репозиториями с помощью Nexus" и Nexus trainer для Sonatype, спонсором бесплатного центрального репозитория, руководителем проекта плагина Android Maven и перенес некоторые библиотеки Android в Central путем восстановления из AOSP.
Ответ 4
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().