Repositorios de comstackción de Android: jcenter VS mavencentral

La última vez que utilicé Android Studio, generó archivos mavencentral() con mavencentral() repositorys de comstackción mientras que ahora hay jcenter() .

¿Alguien podría explicar los problemas relacionados con esto? ¿Hay algún otro repository? ¿Cuándo deberíamos cambiarlos? ¿Qué impacto tienen en proyectos, módulos, libs? Cualquier otro elemento esencial para los desarrolladores de Android?

¿Quién es responsable de mantener esos repos?

En Bintray acabo de publicar una publicación de blog muy detallada que describe los motivos por los que Google hizo este cambio. Estos son los puntos más importantes:

  • JCenter es un repository de Java en Bintray , que es el repository más grande del mundo para bibliotecas, paquetes y componentes de OSS de Java y Android.
  • Todo el contenido en JCenter se sirve a través de un CDN, con una conexión segura HTTPS. De vuelta en el momento de la migración (Android Studio 0.8) El repository central de maven 2 era solo HTTP y HTTPS no era compatible. Referencia: 51.6.2. Repositorio central de Maven .
  • jcenter() es un superconjunto de mavenCentral() , que abarca muchos repositorys y artefactos adicionales.
  • En diferentes escenarios y de diferentes países, Bintray es más rápido que Maven Central (por ejemplo, de Israel). En otros, está muy cerca. Dado que Maven Central y Bintray usan diferentes CDN que favorecen adaptativamente las regiones, esto podría cambiar en ambos sentidos.
  • Bintray tiene un enfoque diferente para la identificación de paquetes que el legado Maven Central. Este es un asunto de seguridad grande y serio. Es importante.
  • Si realmente necesita llevar su paquete a Maven Central (para soportar herramientas heredadas), también puede hacerlo desde Bintray, con un clic de botón o incluso automáticamente .

Con respecto a las mejoras de rendimiento, una pareja de promotores de desarrolladores de Android se había enfrentado al problema de la gran indexación con maven central.

En palabras de Tor Norbye :

Ejecuté AndroidStudio con un nuevo directorio de configuraciones, así que fue y se conectó a Maven Central y descargué un índice de los artefactos disponibles.

Entonces, por casualidad, miré el tamaño de mi directorio.

Mi ~ / Library / Cache / AndroidStudioPreview es 1.5G, y 1.2G de ellos son tomados por el subdirectorio “Maven”.

Eso es ridículo. Apenas usamos el índice en absoluto. El uso principal para esto es el editor de dependencias en el Diálogo de Estructura del Proyecto, pero realmente no necesitamos tener un índice precalculado para él. MavenCentral tiene una rápida búsqueda JSON en línea que podemos usar bajo demanda cuando alguien busca artefactos. En https://android-review.googlesource.com/#/c/94843/ agregamos un control de pelusa que comprueba si las dependencias están actualizadas, y la búsqueda de un puñado de artefactos es casi instantánea.

En resumen, realmente no necesitamos el caché; puede ayudar con la finalización del código en los archivos .gradle y maven .pom, pero ese no es un caso de uso súper importante, y ciertamente no es algo que todos los usuarios deberían sacrificar 1.5G de velocidad de descarga y espacio de disco para tener la posibilidad de hacerlo un día. Lea más en: ¡ El índice de Maven es enorme !

Además, es posible que esta discusión muy breve (1Q y 1A) sobre Hacker News sea interesante.


Estoy con JFrog , la compañía detrás de bintray y artifactory , mira mi perfil para más detalles y enlaces.

Me preguntaba lo mismo, y no tengo una respuesta definitiva, pero pensé que podría valer la pena compartir qué (poco) había aprendido. Encontré una mención de la mudanza de Maven Central a JCenter dentro de un problema en Google Code , pero no detecté detalles sobre cuándo sucedió esto exactamente, no pude encontrar una mención en la lista de cambios recientes para Android Studio.

Después de leer en JCenter, es el repository detrás de Bintray, de la compañía JFrog (con quien me he cruzado antes, y creo que de ahí proviene la ‘J’). Según el blog de Bintray, Bintray es un superconjunto de Maven Central , así que si eso es cierto no debería haber problemas con las dependencias faltantes, pero supongo que dependerá exactamente de lo que estés usando en tus proyectos, siempre podrías hacerlo directamente. revise los repos ya que ambos tienen buenos sitios web fáciles de buscar. Entonces, para quienes mantienen estos repositorys, lo mejor que sé es que los productores de las dependencias deben agregar sus dependencias a cada repository, y hasta el propietario del repository solo para mantener el servicio.

En términos de cuándo cambiarlo, es difícil hacer ejercicio. AOSP todavía usa Maven Central, creo (al buscar en las plantillas para la nueva aplicación de Android), pero esa plantilla también sigue usando una versión Gradle muy antigua (0.4) también. Hay un par de problemas sobre otros que tienen problemas con dependencias de jcenter, pero en realidad no se ha informado mucho, y es posible que Google cambie nuevamente a algún otro repository antes de lanzar el AS final. Si Maven Central todavía funciona bien para usted, por ahora podría esperar hasta que cambie, especialmente si está construyendo grandes soluciones comerciales.

No importa cuál sea el valor predeterminado en el archivo build.gradle: en un esfuerzo de desarrollo basado en equipos, realmente debe usar un administrador de repositorys como Sonatype Nexus o JFrog Artifactory y no hacer referencia directamente a esos repositorys ascendentes.

Esto le permitirá ahorrar mucho ancho de banda, combinar ambos y muchos otros repositorys y administrarlo todo en su propia red.

En términos de Maven Central vs JCenter. JCenter es el esfuerzo de JFrog para abrazar, extender (y exterminar?) Maven Central. Maven Central es el repository predeterminado en Maven, SBT y otros, mientras que Gradle ha cambiado a JCenter. Esto no es sorprendente teniendo en cuenta que JFrog y Gradleware trabajan juntos como empresas. Dado que el Android SDK usa ahora Gradle como sistema de comstackción, el paso a JCenter fue el siguiente paso lógico.

JCenter en sí es una fina capa sobre Maven Central. Proxies (con mayor o menor éxito) y agrega componentes adicionales. Ambos están alojados en redes CDN y tienen un alto rendimiento. Maven Central en sí es el objective para todos los proyectos de código abierto Eclipse, Apache y la mayoría de los demás, y sin él JCenter estaría prácticamente vacío.

Usar cualquiera de ellos funcionará bien, pero yo sugeriría ir directamente a la fuente donde usted pueda y, además, tomar el control utilizando un administrador de repositorys. Nexus Open Source, por ejemplo, es gratuito y tiene soporte para repositorys Maven como los utilizados por Maven, Gradle, SBT, Ivy y otros, así como compatibilidad con NuGet, NPM y RubyGems.

Descargo de responsabilidad: soy el autor de Repository Management con Nexus y Nexus trainer para Sonatype, el patrocinador del repository central gratuito, el líder del proyecto de Android Maven Plugin y he llevado algunas bibliotecas de Android a Central reconstruyendo desde AOSP.

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

este artículo puede responderte pregunta.

Al principio, Android Studio eligió Maven Central como repository predeterminado. Una vez que haya creado un nuevo proyecto a partir de la versión anterior de Android Studio, mavenCentral () se definirá automáticamente en build.gradle.

Pero el gran problema de Maven Central es que no es amigable para los desarrolladores. Es sorprendentemente difícil cargar la biblioteca en. Para poder hacerlo, el desarrollador debe estar en algún nivel de geek. Y con alguna razón más, por ejemplo, un problema de seguridad, etc., el equipo de Android Studio decidió cambiar el repository predeterminado a jcenter, ya que puede ver que una vez que crea un nuevo proyecto a partir de la última versión de Android Studio, jcenter () se define automáticamente en lugar de mavenCentral ().