L'annotazione javadoc Android Gradle non esiste

Question

Sto provando a creare un aar da pubblicare su jcenter.

Il compito assembleRelease funziona bene, il compito javadoc funziona anche bene, ma le uscite compito javadocJar questo errore:

/Users/martinmoreno/Projects/android-dev-utils/dev-utils/src/main/java/com/tinchoapps/devutils/BitmapUtils.java:11: error: package android.support.annotation does not exist 
import android.support.annotation.NonNull; 

Ecco la (semplificato) File Gradle:

apply plugin: 'com.android.library' 
apply plugin: 'com.github.dcendents.android-maven' 


android { 
    ... 
    buildTypes { 
     release { 
      minifyEnabled false 
      shrinkResources false 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' 
      signingConfig signingConfigs.debug 
     } 
    } 
... 
} 

... 

dependencies { 
    compile fileTree(include: ['*.jar'], dir: 'libs') 
    compile 'com.android.support:support-annotations:20.0.0' 
    compile 'com.android.support:support-v4:22.0.0' 
} 

task sourcesJar(type: Jar) { 
    from android.sourceSets.main.java.srcDirs 
    classifier = 'sources' 
} 

task javadoc(type: Javadoc) { 
    source = android.sourceSets.main.java.srcDirs 
    classpath += project.files(android.getBootClasspath().join(File.pathSeparator)) 
    destinationDir = file("../javadoc/") 
} 

task javadocJar(type: Jar, dependsOn: javadoc) { 
    classifier = 'javadoc' 
    from javadoc.destinationDir 
} 

artifacts { 
    archives sourcesJar 
    archives javadocJar 
} 

Sembra correlato alle dipendenze perché fornisce alcune eccezioni di "classe non trovata" anche sulle classi all'interno delle importazioni, ma non riesce a capire cosa c'è che non va.

Qualche idea?

Answer 1

questo riparato vari errori simili per me:

aggiungere quanto segue build.gradle:

configurations { 
    javadocDeps 
} 

dependencies { 
    compile 'com.android.support:support-annotations:22.2.0' 
    javadocDeps 'com.android.support:support-annotations:22.2.0' 
    androidTestCompile 'junit:junit:4.+' 
    androidTestCompile 'com.jayway.android.robotium:robotium-solo:+' 
} 

Nel JavaDoc Task aggiungere questa linea:

classpath += configurations.javadocDeps 

Answer 2

ho affrontato questo durante l'esecuzione di ./gradlew install. Stava succedendo quando venivano compilati i JavaDocs (per quanto posso capire).

Ho appena aggiunto failOnError false a task javadoc.

task javadoc(type: Javadoc) { 
    source = android.sourceSets.main.java.srcDirs 
    classpath += project.files(android.getBootClasspath().join(File.pathSeparator)) 
    failOnError false 
} 

Quello che ho capito è che abbiamo evitato errori su avvisi che la libreria di annotazioni non è stata trovata.

Answer 3

Basta aggiungere questa linea nel vostro compito Javadoc (notate l'ultima parte: + configurations.compile):

classpath += project.files(android.getBootClasspath().join(File.pathSeparator)) + configurations.compile 

L'ultima parte della linea si assicura che il javadoc utilizzare le dipendenze di compilazione per risolvere le classi che sta utilizzando per javadoc . A questo punto, non dovrebbe fallire più.

Answer 4

seguito dalla risposta di Markus, questo è come ho dovuto farlo per farlo funzionare:

configurations { 
    javadocDeps 
} 

dependencies { 
    compile 'com.android.support:support-annotations:25.3.1' 
    javadocDeps 'com.android.support:support-annotations:25.3.1' 
} 

tasks.whenTaskAdded { task -> 
    if (task.name == 'androidJavadocs') { 
     task.configure { 
      classpath += configurations.javadocDeps 
     } 
    } 
} 

Answer 5

Dopo l'introduzione della configurazione delle dipendenze api e implementation in Android Gradle 3.0.0, compile è deprecato. Per includere un implementation dipendenza nel classpath javadoc, ho aggiornato Loius CADs answer:

task javadoc(type: Javadoc) { 
    source = android.sourceSets.main.java.srcDirs 
    configurations.implementation.setCanBeResolved(true) 
    classpath += project.files(android.getBootClasspath().join(File.pathSeparator)) + configurations.implementation 
} 

non mi aspetto che questo sia la soluzione più pulita possibile. Probabilmente c'è una ragione per cui configuration.implementation non è risolvibile per impostazione predefinita.