2014-09-24 14 views
10

Sto lavorando a un progetto che include due progetti di libreria Android. Quando carico queste librerie sul mio repository Maven (Nexus), il pom generato non include un elemento <type>aar</type> nella dipendenza.dipendenze transitori progetto libreria Android allentate tipo AAR

Ecco il mio albero delle dipendenze

* App1 
\ 
    * lib1 
    |\ 
    | * lib2 
    * Other libs 

Si può vedere in questo diagramma che il mio app dipende lib1, che dipende lib2. Entrambe le librerie sono progetti di librerie Android, quindi AAR.

Lib1/build.gradle

apply plugin: 'com.android.library' 
apply from: 'https://raw.github.com/chrisbanes/gradle-mvn-push/master/gradle-mvn-push.gradle' 

android { 
    compileSdkVersion rootProject.ext.compileSdkVersion 
    buildToolsVersion rootProject.ext.buildToolsVersion 

    defaultConfig { 
     minSdkVersion rootProject.ext.minSdkVersion 
     targetSdkVersion 20 
     versionCode 1 
     versionName "1.0" 
    } 
} 

dependencies { 
    compile fileTree(dir: 'libs', include: ['*.jar']) 
    provided project(':lib2') 

    compile 'com.squareup.picasso:picasso:2.3.3' 
} 

LIB2/build.gradle

apply plugin: 'com.android.library' 
apply from: 'https://raw.github.com/chrisbanes/gradle-mvn-push/master/gradle-mvn-push.gradle' 

android { 
    compileSdkVersion rootProject.ext.compileSdkVersion 
    buildToolsVersion rootProject.ext.buildToolsVersion 

    defaultConfig { 
     minSdkVersion rootProject.ext.minSdkVersion 
     targetSdkVersion 19 
     versionCode 1 
     versionName '1.0' 
    } 
} 

dependencies { 
    compile fileTree(dir: 'libs', include: ['*.jar']) 
    compile 'com.android.support:appcompat-v7:19.+' 
    compile 'com.squareup.retrofit:retrofit:1.6.1' 
    compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0' 
    compile 'com.squareup.okhttp:okhttp:2.0.0' 
} 

Notate come Lib1 include Lib2 come una dipendenza project().

Ora, quando lo utilizzo utilizzando l'eccellente plugin gradle-mvn-push di Chris Banes, tutto funziona come previsto. C'è solo una stranezza che noto nel pom.xml generato.

<dependencies> 
    <dependency> 
     <groupId>com.example</groupId> 
     <artifactId>lib2</artifactId> 
     <version>0.0.1-SNAPSHOT</version> 
     <scope>compile</scope> 
    </dependency> 
    ... 
</dependencies> 

Si noti che il plugin mavenDeployer lasciato fuori l'elemento <type>aar</type> in dipendenza, quando ha generato il pom.

Nel mio progetto app (che è un progetto Maven), ho questa dipendenza elencati:

<dependencies> 
    <dependency> 
     <groupId>com.example</groupId> 
     <artifactId>lib1</artifactId> 
     <version>0.0.1-SNAPSHOT</version> 
     <type>aar</type> 
    </dependency> 
    ... 
</dependencies> 

Quando si cerca di costruire questo con Maven, ottengo l'errore seguente.

Could not resolve dependencies for project com.example:app:apk:1.0.0-SNAPSHOT: The following artifacts could not be resolved: com.example:lib2:jar:0.0.1-SNAPSHOT 

Nota come sta cercando una versione jar della libreria. Credo che, dal momento che il plugin mavenDeployer non sia stato generato con lo <type>aar</type> nell'elenco delle dipendenze del pom generato, Maven è in via di definizione alla ricerca di un jar.

Qualcuno sa come costruire progetti di librerie Android che includono dipendenze temporanee con Gradle?

+2

Lo stesso problema qui. – sarfata

risposta

0

Basta aggiungere l'aar al pom con qualsiasi editor di testo. Dopodiché, apri una console nella root del progetto (dove si trova il pom) ed esegui "mvn clean install". L'artefatto di aar sarà generato e distribuito al tuo repository Maven.

In ogni caso, è molto più facile creare librerie aar con Maven. Basta creare un Progetto Maven usando qualsiasi archetipo di libreria Android (quelli de.akquinet sono piuttosto buoni, ma devi usare una versione plugin tra 3.8.2 e 3.9, http://mvnrepository.com/artifact/de.akquinet.android.archetypes). Basta creare il progetto, aggiungere le librerie e quindi eseguire il comando "mvn clean install" per installarli nella tua directory di maven locale. Dopo di ciò, basta usarli come normali dipendenze.

+0

Il problema non è nella creazione di progetti di libreria, è che un progetto di libreria con dipendenze su altre librerie AAR, quando distribuito usando mavenDeployer (uploadArchives), non conserva la parte aar dell'elemento di dipendenza nel pom, quindi maven prova a risolvere queste dipendenze transitori come vasi (il default). – rharter

+0

Lo capisco. Ma supponendo che tutto il resto del pom sia a posto, basta aggiungere il tipo mancante ed eseguire Maven manualmente genererebbe i remi. –

+0

Certo, ma a quel punto sto costruendo manualmente le mie dipendenze, il che nega il vantaggio di gestione delle dipendenze automatico che utilizzo per Maven. Devo essere in grado di distribuire librerie che dipendono da altre librerie senza l'avvertenza che ogni utente ha bisogno di scaricare manualmente le dipendenze, modificare il pom e costruirle localmente. – rharter

0

Prova gradle-furia. Corregge tutto questo ... ehm ... roba. Specificamente i pom non validi e/o inaccurati che sono generati da gradle. Soluzione di lavoro confermata da pubblicare su sonatype oss/maven central. Nessuna modifica pom manuale, supporto firma pgp e molto altro ancora.

sito: https://github.com/gradle-fury/gradle-fury

In particolare, è necessario lo script Gradle Maven-support, che fa tutto il lavoro per voi. Tutte le cose che sono normalmente nel pom sono memorizzate in gradle.properties. Supporta anche varianti Android, file di guerra, (presto correzioni per distZip), javadoc e sorgenti e altro.

di responsabilità, io lavoro su di esso

Edit: un altro frammento di informazione. Sebbene la furia faccia da inetta alle dipendenze e corregga la digitazione per le librerie AAR, il plugin gradle-android (la roba che google fa) non onora la sezione delle dipendenze e la ignora. Le dipendenze fondamentalmente transitive dei progetti AAR non sono supportate. Nessuna idea del perché

Problemi correlati