java - google - Repositorios de buildscript de Android: jcenter VS mavencentral

build.gradle android (4)

La última vez que utilicé Android Studio, .gradle archivos mavencentral() con repositorios de scripts mavencentral() mientras que ahora hay jcenter() .

¿Podría alguien explicar los problemas relacionados con esto? ¿Hay otros repositorios? ¿Cuándo debemos cambiarlos? ¿Qué impacto tienen en los proyectos, módulos, librerías? ¿Algún otro elemento esencial para los desarrolladores de Android?

¿Quién es responsable de mantener esos repositorios?

En Bintray acabo de publicar una publicación de blog muy detallada que describe las razones por las que Google hizo este cambio. Aquí están los puntos más importantes:

JCenter es un repositorio de Java en Bintray , que es el repositorio más grande del mundo para bibliotecas, paquetes y componentes OSS de Java y Android.
Todo el contenido en JCenter se sirve a través de un CDN, con una conexión HTTPS segura. En el momento de la migración (Android Studio 0.8) El repositorio central de maven 2 era solo HTTP y no se admitía HTTPS. Referencia: 51.6.2. Repositorio central de Maven .
jcenter() es un superconjunto de mavenCentral() , que abarca muchos depósitos y artefactos adicionales.
En diferentes escenarios y de diferentes países, Bintray es más rápido que Maven Central (por ejemplo, desde Israel). En otros está muy cerca. Dado que Maven Central y Bintray utilizan diferentes CDN que favorecen adaptativamente a 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 admitir herramientas heredadas), también puede hacerlo desde Bintray, con un solo clic o incluso de forma automática .

Con respecto a las mejoras de rendimiento, un par de defensores de los desarrolladores de Android se habían enfrentado / notado el problema de la gran indexación con Maven Central.

En palabras de Tor Norbye :

Corrí AndroidStudio con un nuevo directorio de configuraciones, así que conecté a maven central y descargué un índice de los artefactos disponibles.
Entonces me encontré con el tamaño de mi directorio.
Mi ~ / Library / Cache / AndroidStudioPreview es 1.5G, y 1.2G son tomadas por el subdirectorio "Maven".
Eso es ridículo. Apenas usamos el índice en absoluto. El uso principal es el editor de dependencias en el cuadro de diálogo Estructura del proyecto, pero realmente no necesitamos tener un índice precalculado para ello. MavenCentral tiene una búsqueda rápida en línea de JSON que podemos usar a pedido cuando alguien busca artefactos. En https://android-review.googlesource.com/#/c/94843/ agregamos una verificación de pelusas que verifica 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 a completar el código en los archivos .gradle y maven .pom, pero eso no es un caso de uso muy importante, y ciertamente no es algo que todos los usuarios deban sacrificar 1.5G de velocidad de descarga y espacio en disco para tener la posibilidad de hacerlo algún día. Lea más en: ¡ El índice de Maven es enorme !

Además, puede encontrar interesante este breve debate (1Q y 1A) sobre Hacker News .

^{Estoy con JFrog , la compañía detrás de bintray y artifactory , vea JBaruch para detalles y enlaces.}

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

Después de leer sobre JCenter, es el repositorio detrás de Bintray, de la compañía JFrog (con quien me he encontrado antes, y supongo que de ahí viene la ''J''). De acuerdo con el blog de Bintray, Bintray es un superconjunto de Maven Central , por lo que si es cierto, no debería haber problemas con dependencias faltantes, pero creo que dependerá de lo que estés usando en tus proyectos, siempre puedes hacerlo directamente. Compruebe los repositorios, ya que ambos tienen buenos sitios web de fácil búsqueda. Entonces, para quién mantiene estos repositorios, como mejor sé, depende de los productores de las dependencias agregar sus dependencias a cada repositorio, y del propietario del repositorio solo para mantener el servicio.

En términos de cuándo cambiar es difícil calcularlo. AOSP sigue usando Maven Central, creo (de buscar en Plantillas para la nueva aplicación de Android), pero esa plantilla también usa una versión muy antigua de Gradle (0.4) también. Hay un par de problemas sobre otros que tienen problemas con las dependencias de jcenter, pero en realidad no se informa mucho, y es posible que Google cambie de nuevo a otro repositorio antes de lanzar AS final. Si Maven Central aún funciona bien para usted por ahora, podría suspender el cambio hasta entonces, 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 equipo, realmente debe usar un administrador de repositorio como Sonatype Nexus o JFrog Artifactory y no hacer referencia a los repositorios de upstream directamente.

Esto le permitirá ahorrar una gran cantidad de ancho de banda, combinar ambos y muchos otros repositorios y administrarlo todo en su propia red.

En términos de Maven Central vs JCenter. JCenter es un esfuerzo de JFrog para abrazar, extender (y exterminar) a Maven Central. Maven Central es el repositorio predeterminado en Maven, SBT y otros, mientras que Gradle ha cambiado a JCenter. Esto no es sorprendente considerando que JFrog y Gradleware trabajan juntos como compañías. Como el SDK de Android usa Gradle como sistema de compilación ahora, el paso a JCenter fue el siguiente paso lógico.

JCenter en sí es una chapa delgada en la parte superior de Maven Central. Lo distribuye (con más o menos éxito) y agrega componentes adicionales. Ambos están alojados en redes CDN y de alto rendimiento. Maven Central en sí mismo es el objetivo de todos los proyectos de código abierto Eclipse, Apache y la mayoría de los demás, y sin él, JCenter estaría casi vacío.

El uso de cualquiera de ellos funcionará bien, pero sugeriría ir directamente a la fuente donde pueda y, además, controlarlo mediante el uso de un administrador de repositorio. Nexus Open Source, por ejemplo, es gratuito y tiene soporte para los repositorios de Maven que utilizan Maven, Gradle, SBT, Ivy y otros, así como el soporte de NuGet, NPM y RubyGems.

Descargo de responsabilidad: soy el autor de Repository Management with Nexus y Nexus trainer para Sonatype, patrocinador del Central Repository gratuito, el líder del proyecto de Android Maven Plugin y he enviado algunas bibliotecas de Android a Central mediante la reconstrucción de AOSP.

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

Este artículo puede responder su pregunta.

Al principio, Android Studio eligió a Maven Central como un repositorio predeterminado. Una vez que cree 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 subir la biblioteca a. Para poder hacerlo, el desarrollador tiene que estar en algún nivel de geek. Y, por alguna razón más, por ejemplo, un problema de seguridad y etc., el equipo de Android Studio decidió cambiar el repositorio predeterminado a jcenter, ya que puede ver que una vez que cree un nuevo proyecto a partir de la última versión de Android Studio, jcenter () se definirá automáticamente. En lugar de mavenCentral ().