Repository buildscript per Android: jcenter VS mavencentral

L'ultima volta che ho usato Android Studio, ha generato .gradlefile con mavencentral()repository buildscript mentre ora c'è jcenter().

Qualcuno potrebbe spiegare i problemi connessi con questo. Ci sono altri repository? Quando dovremmo cambiarli? Che impatto hanno su progetti, moduli, librerie? Altri elementi essenziali per gli sviluppatori Android?

Chi è responsabile del mantenimento di tali repository?

A Bintray ho appena rinnovato un post di blog molto dettagliato che descrive i motivi per cui Google ha apportato questa modifica. Ecco i punti più importanti:

• JCenter è un repository Java in Bintray , il più grande repository al mondo per librerie, pacchetti e componenti OSS Java e Android.
• Tutto il contenuto in JCenter viene servito su una rete CDN, con una connessione HTTPS sicura. Indietro nel tempo della migrazione (Android Studio 0.8) Il repository centrale maven 2 era solo HTTP e HTTPS non era supportato. Riferimento: 51.6.2. Archivio centrale di Maven .
• jcenter()è un superset di mavenCentral(), che comprende molti repository e manufatti aggiuntivi.
• In diversi scenari e da diversi paesi, Bintray è più veloce di Maven Central (ad es. Da Israele). In altri è molto vicino. Poiché Maven Central e Bintray utilizzano CDN diversi che favoriscono in modo adattivo le regioni, questo potrebbe cambiare in entrambi i modi.
• Bintray ha un approccio diverso all'identificazione del pacchetto rispetto al precedente Maven Central. Questa è una questione di sicurezza grande e seria. È importante.
• Se hai davvero bisogno di portare il tuo pacchetto su Maven Central (per supportare gli strumenti legacy) puoi farlo anche da Bintray, con un clic di un pulsante o anche automaticamente .

Per quanto riguarda i miglioramenti delle prestazioni, un paio di sostenitori degli sviluppatori Android hanno affrontato / notato il problema dell'enorme indicizzazione con Maven Central.

Nelle parole di Tor Norbye :

Ho eseguito AndroidStudio con una nuovissima directory di impostazioni, quindi è andato e mi sono collegato maven central e scaricato un indice dei manufatti disponibili.

Poi mi è capitato di guardare le dimensioni della mia directory.

My ~ / Library / Cache / AndroidStudioPreview è 1.5G e 1.2G di questi sono presi dalla sottodirectory “Maven”.

È ridicolo. Usiamo a malapena l'indice. L'uso principale è l'editor di dipendenze nella finestra di dialogo Struttura del progetto, ma non è necessario disporre di un indice precompilato per esso. MavenCentral ha una rapida ricerca JSON online che possiamo usare su richiesta quando qualcuno cerca artefatti. In https://android-review.googlesource.com/#/c/94843/ abbiamo aggiunto un controllo lanugine che controlla se le dipendenze sono aggiornate e la ricerca di una manciata di artefatti è quasi istantanea.

In breve, non abbiamo davvero bisogno della cache; può aiutare con il completamento del codice nei file .gradle e maven .pom, ma non è un caso d'uso molto importante, e certamente non è qualcosa che tutti gli utenti dovrebbero sacrificare 1,5 G di velocità di download e spazio su disco per avere la possibilità di farlo un giorno. Maggiori informazioni su: L'indice Maven è enorme !

Inoltre, potresti trovare interessante questa breve discussione (1Q e 1A) su Hacker News .

^{Sono con JFrog , la compagnia dietrobintray e Artifactory, vedere il mio profilo per dettagli e collegamenti.}

Mi chiedevo lo stesso, e non ho una risposta definitiva, ma ho pensato che valesse la pena condividere ciò che (poco) avevo imparato. Ho trovato la menzione del passaggio da Maven Central a JCenter all'interno di un problema su Google Code , ma non ho trovato dettagli su esattamente quando ciò è accaduto - non sono riuscito a trovare menzione nell'elenco delle modifiche recenti per Android Studio.

Dalla lettura su JCenter, è il repository dietro Bintray, della società JFrog (che ho incontrato prima, e immagino che sia da lì che viene la "J"). Secondo il blog di Bintray, Bintray è un superset di Maven Central , quindi se questo è vero non dovrebbero esserci problemi con le dipendenze mancanti, ma immagino che dipenderà esattamente da ciò che stai usando nei tuoi progetti: potresti sempre direttamente controlla i repository poiché entrambi hanno dei siti web facilmente ricercabili. Quindi, per chi mantiene questi repository, come meglio conosco, spetta ai produttori delle dipendenze aggiungere le loro dipendenze a ciascun repository e al proprietario del repository solo per mantenere il servizio.

In termini di quando cambiare è difficile allenarsi. Penso che AOSP stia ancora usando Maven Central (dalla ricerca in Modelli per la nuova applicazione Android), ma poi quel modello usa ancora anche una versione Gradle molto vecchia (0.4). Ci sono un paio di problemi su altri che hanno problemi con le dipendenze da jcenter, ma non molto segnalati, ed è possibile che Google passi nuovamente ad altri repository prima di rilasciare AS final. Se per ora Maven Central funziona ancora bene per te, puoi smettere di cambiare fino ad allora, specialmente se stai costruendo grandi soluzioni commerciali.

Indipendentemente dall'impostazione predefinita nel file build.gradle, in uno sforzo di sviluppo basato su team è necessario utilizzare un gestore di repository come Sonatype Nexus o JFrog Artifactory e non fare riferimento direttamente a questi repository a monte.

Ciò ti consentirà di risparmiare molta larghezza di banda, combinare entrambi e molti altri repository e gestirli tutti nella tua rete.

In termini di Maven Central vs JCenter. JCenter è lo sforzo di JFrog per abbracciare, estendere (e sterminare?) Maven Central. Maven Central è il repository predefinito in Maven, SBT e altri, mentre Gradle è passato a JCenter. Ciò non sorprende se si considera che JFrog e Gradleware lavorano insieme come aziende. Poiché l'SDK di Android utilizza Gradle come sistema di build ora, il passaggio a JCenter è stato un passo logico successivo.

JCenter stesso è una sottile impiallacciatura sulla parte superiore di Maven Central. Lo proxy (più o meno correttamente) e aggiunge componenti aggiuntivi. Entrambi sono ospitati su reti CDN e altamente performanti. Maven Central stesso è l'obiettivo di tutti i progetti Eclipse, Apache e la maggior parte degli altri progetti open source e senza di essa JCenter sarebbe per lo più vuoto.

Usando uno di loro funzionerà bene, ma suggerirei di andare direttamente alla fonte dove puoi e per di più prenderne il controllo usando un gestore di repository. Nexus Open Source, ad esempio, è gratuito e supporta i repository Maven utilizzati da Maven, Gradle, SBT, Ivy e altri, nonché il supporto NuGet, NPM e RubyGems.

Disclaimer: sono l'autore di Repository Management con Nexus e trainer Nexus per Sonatype, sponsor del repository centrale gratuito, capo del progetto del plug-in Maven per Android e ho inviato alcune librerie Android a Central ricostruendo da AOSP.

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

questo articolo può rispondere alla tua domanda.

Inizialmente, Android Studio ha scelto Maven Central come repository predefinito. Una volta creato un nuovo progetto dalla vecchia versione di Android Studio, mavenCentral () verrebbe automaticamente definito in build.gradle.

Ma il grosso problema di Maven Central è che non è favorevole agli sviluppatori. È sorprendentemente difficile caricare la libreria in. Per essere in grado di farlo, lo sviluppatore deve essere ad un certo livello di geek. E con qualche motivo in più, ad esempio un problema di sicurezza, ecc., Il team di Android Studio ha deciso di passare al repository predefinito in jcenter invece come puoi vedere una volta creato un nuovo progetto dall'ultima versione di Android Studio, jcenter () sarebbe automaticamente definito invece di mavenCentral ().