Repositórios do buildscript do Android: jcenter VS mavencentral

A última vez que usei o Android Studio, ele gerou .gradlearquivos com mavencentral()repositórios buildscript, enquanto agora existe jcenter().

Alguém poderia explicar os problemas relacionados a isso. Existem outros acordos de recompra? Quando devemos trocá-los? Qual o impacto que eles têm em projetos, módulos, bibliotecas? Quaisquer outros itens essenciais para desenvolvedores do Android?

Quem é responsável por manter esses compromissos?

Na Bintray, acabei de publicar um post muito detalhado descrevendo os motivos pelos quais o Google fez essa alteração. Aqui estão os pontos mais importantes:

• O JCenter é um repositório Java no Bintray , o maior repositório do mundo para bibliotecas, pacotes e componentes Java e Android OSS.
• Todo o conteúdo do JCenter é veiculado em uma CDN, com uma conexão HTTPS segura. No tempo da migração (Android Studio 0.8) O repositório central do maven 2 era apenas HTTP e HTTPS não era suportado. Referência: 51.6.2. Maven repositório central .
• jcenter()é um superconjunto de mavenCentral(), que abrange muitos repositórios e artefatos adicionais.
• Em diferentes cenários e de diferentes países, a Bintray é mais rápida que o Maven Central (por exemplo, de Israel). Em outros, é muito próximo. Como o Maven Central e o Bintray usam CDNs diferentes que favorecem regiões de maneira adaptativa, isso pode mudar para os dois lados.
• O Bintray tem uma abordagem diferente para identificação de pacotes do que o Maven Central legado. Essa é uma questão de segurança grande e séria. É importante.
• Se você realmente precisa levar seu pacote para o Maven Central (para suporte a ferramentas herdadas), também pode fazê-lo na Bintray, com apenas um clique de um botão ou até automaticamente .

Em relação às melhorias de desempenho, alguns defensores dos desenvolvedores de Android enfrentaram / notaram o problema da enorme indexação com o maven central.

Nas palavras de Tor Norbye :

Executei o AndroidStudio com um novo diretório de configurações, por isso ele foi conectado ao maven central e baixado um índice dos artefatos disponíveis.

Por acaso, observei o tamanho do meu diretório.

Meu ~ / Library / Cache / AndroidStudioPreview é 1.5G, e 1.2G desses são usados ​​pelo subdiretório "Maven".

Isso é ridículo. Mal usamos o índice. O principal uso para isso é o editor de Dependências no diálogo de estrutura do projeto, mas realmente não precisamos ter um índice pré-computado para isso. O MavenCentral possui uma rápida pesquisa JSON on-line que podemos usar sob demanda quando alguém procura artefatos. Em https://android-review.googlesource.com/#/c/94843/ , adicionamos uma verificação de fiapos que verifica se as dependências estão atualizadas e a busca por alguns artefatos é quase instantânea.

Em resumo, realmente não precisamos do cache; pode ajudar na conclusão do código nos arquivos .gradle e maven .pom, mas não é um caso de uso super importante e, certamente, não é algo todos os usuários devem sacrificar em 1,5 G de velocidade de download e espaço em disco para ter a possibilidade de um dia fazer. Leia mais em: O índice Maven é enorme !

Além disso, você pode achar interessante essa discussão muito curta (1T e 1A) sobre o Hacker News .

^{Estou com a JFrog , a empresa por trásbandeja e artefato, consulte meu perfil para obter detalhes e links.}

Eu estava pensando o mesmo, e não tenho uma resposta definitiva, mas achei que poderia valer a pena compartilhar o que (pouco) eu aprendi. Encontrei menção da mudança do Maven Central para o JCenter em um problema no Google Code , mas não localizei detalhes exatamente quando isso aconteceu - não consegui encontrar menção na lista de alterações recentes do Android Studio.

Desde a leitura no JCenter, é o repositório por trás da Bintray, da empresa JFrog (com quem já me deparei antes, e acho que é daí que vem o 'J'). De acordo com o blog da Bintray, a Bintray é um superconjunto do Maven Central ; portanto, se isso é verdade, não deve haver problemas com dependências ausentes, mas acho que vai depender exatamente do que você está usando em seus projetos - você sempre pode diretamente verifique os repositórios, pois ambos têm sites agradáveis ​​e facilmente pesquisáveis. Portanto, para quem mantém esses repositórios, como eu sei, cabe aos produtores das dependências adicionar suas dependências a cada repositório e ao proprietário do repositório apenas para manter o serviço.

Em termos de quando mudar, é difícil resolver. Acho que o AOSP ainda está usando o Maven Central (ao procurar em Modelos para novos aplicativos Android), mas esse modelo também ainda está usando uma versão Gradle (0.4) muito antiga. Existem alguns problemas em relação a outros que têm problemas com as dependências do jcenter, mas não há muitos relatórios, e é possível que o Google mude novamente para outro repo antes de lançar o AS final. Se o Maven Central ainda estiver funcionando bem para você por enquanto, você poderá adiar a troca até então, especialmente se estiver criando grandes soluções comerciais.

Não importa qual seja o padrão no arquivo build.gradle - em um esforço de desenvolvimento baseado em equipe, você realmente deve usar um gerenciador de repositório como o Sonatype Nexus ou o JFrog Artifactory e não referenciar esses repositórios upstream diretamente.

Isso permitirá que você economize muita largura de banda, combine ambos e muitos outros repositórios e gerencie tudo em sua própria rede.

Em termos de Maven Central vs JCenter. O JCenter é um esforço do JFrog para abraçar, estender (e exterminar?) O Maven Central. O Maven Central é o repositório padrão no Maven, SBT e outros, enquanto o Gradle mudou para o JCenter. Isso não surpreende, considerando que o JFrog e o Gradleware trabalham juntos como empresas. Como o SDK do Android usa o Gradle como sistema de compilação agora, a mudança para o JCenter foi o próximo passo lógico.

O JCenter em si é um revestimento fino em cima do Maven Central. Ele o proxies (com mais ou menos sucesso) e adiciona componentes adicionais. Ambos estão hospedados em redes CDN e têm alto desempenho. O Maven Central em si é o alvo de todos os projetos de código aberto do Eclipse, Apache e da maioria dos outros aplicativos de código aberto, e sem ele o JCenter ficaria praticamente vazio.

O uso de qualquer um deles funcionará bem, mas eu sugiro ir direto à fonte onde você puder e, além disso, assumir o controle usando um gerenciador de repositório. O Nexus Open Source, por exemplo, é gratuito e tem suporte para repositórios Maven, usados ​​por Maven, Gradle, SBT, Ivy e outros, além do NuGet, NPM e RubyGems.

Isenção de responsabilidade: eu sou o autor do Repository Management with Nexus e do Nexus trainer da Sonatype, o patrocinador do Central Repository gratuito, o líder do projeto do Android Maven Plugin e levei algumas bibliotecas Android para a Central, reconstruindo a partir do AOSP.

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

Este artigo pode responder sua pergunta.

No início, o Android Studio escolheu o Maven Central como repositório padrão. Depois de criar um novo projeto a partir da versão antiga do Android Studio, o mavenCentral () será definido automaticamente em build.gradle.

Mas o grande problema do Maven Central é que ele não é amigável ao desenvolvedor. É surpreendentemente difícil fazer upload da biblioteca para. Para poder fazer isso, o desenvolvedor precisa estar em algum nível de nerd. E com mais algum motivo, por exemplo, uma preocupação de segurança e etc., a equipe do Android Studio decidiu mudar o repositório padrão para o jcenter, como você pode ver que, depois de criar um novo projeto a partir da versão mais recente do Android Studio, o jcenter () seria definido automaticamente em vez de mavenCentral ().