2014-06-19 13 views
5

Stiamo utilizzando Android Studio 0.6.1 con il plug-in Gradle 0.11. + Nel nostro progetto corrente e stiamo riscontrando un problema di dipendenze con commons-codec. Stiamo tirando in una classe di dipendenza dal nostro esempio Artifactory locale che contiene un servizio di "crypto" che utilizza le seguenti due righe di codice:Problema delle dipendenze Base64 in Android Studio

byte[] encryptedOutput = cipherFactory.getEncryptCipher().doFinal(plaintext.getBytes()); 
byte[] encryptedCipherText = Base64.encodeBase64URLSafe(encryptedOutput); 

Il problema è che anche se si definisce una dipendenza specifica di commons-codec in la nostra configurazione Gradle, otteniamo la seguente eccezione

java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64URLSafe 

in un primo momento, ci siamo includiamo manualmente una dipendenza per 'commons-codec: commons-codec: 1.9', ma secondo Android Studio quando mi drill-down nei codice nell'IDE, sta guardando la versione di quel metodo in 1.9, ma quando l'app viene eseguita, otteniamo l'eccezione. Anche cambiando la dipendenza in 1.4 continua a fallire, anche se, secondo Javadocs, quel metodo è diventato disponibile. Anche la rimozione della dipendenza manuale causa la stessa cosa.

Esiste un modo per scoprire da dove proviene questa dipendenza? Questa è la nostra lista completa delle dipendenze in questo momento, e non riesco a trovare commons-codec da uno di questi

compile files('libs/HockeySDK-3.0.2.jar') 
compile files('libs/PushIOManager.jar') 
compile 'commons-lang:commons-lang:[email protected]' 
compile 'org.codehaus.jackson:jackson-core-asl:[email protected]' 
compile 'org.codehaus.jackson:jackson-mapper-asl:[email protected]' 
compile 'com.google.android.gms:play-services:4.4.52' 
compile 'com.mcxiaoke.volley:library:1.0.4' 
compile 'fr.avianey:facebook-android-api:[email protected]' 
compile 'javax.validation:validation-api:1.0.0.GA' 

La mia paura è che questa classe è sepolto da qualche parte con l'SDK di Android e dovremo alcun modo per ignorare per utilizzare una versione di commons-codec che ci consentirà di utilizzare la nostra libreria. E anche se potessimo farlo, sono preoccupato di farlo potrebbe causare alcuni problemi fondamentali con Android stesso. Possiamo (e al momento lo facciamo) avere la fonte per quella classe di servizio cripto inserita nella nostra app e averla ottimizzata per usare l'equivalente appropriato, ma questo significa che ogni volta che apportiamo una modifica all'una o all'altra versione, dovremmo tenere li in sincrono.

Qualche idea?

AGGIORNAMENTO: Ciò che sembra funzionare in questo caso specifico è la scansione delle dipendenze nei file di build Gradle e una volta trovata la dipendenza che si sta cercando, l'override è con la versione che si desidera utilizzare. Per esempio:

def versionOverrides = [ 
    "commons-codec:commons-codec": "1.9", 
] 

subprojects { 
    configurations.all { 
     resolutionStrategy.eachDependency { DependencyResolveDetails details -> 

      def overrideVersion = versionOverrides[details.requested.group + ":" + details.requested.name] 

      if (overrideVersion != null && details.requested.version != overrideVersion) { 
       logger.info "Overriding dependency ${details.requested.group}:${details.requested.name} version ${details.requested.version} --> $overrideVersion" 
       details.useVersion overrideVersion 
      } 
     } 
    } 
} 
+0

Prova 'dipendenze gradle' –

risposta

1

La mia paura è che questa classe è sepolto da qualche parte con l'SDK di Android e dovremo alcun modo per ignorare in modo da utilizzare una versione di commons-codec che ci permetterà di utilizzare il nostro biblioteca.

Questo è esattamente ciò che sta accadendo.
Il classloader di avvio è precaricato con classi dalla versione 1.3 della libreria di Commons Codec.

È possibile riconfezionare (rinominare il pacchetto/spazio dei nomi delle classi) la libreria di Commons Codec per evitare questo conflitto. Vedere la mia risposta here per una descrizione più dettagliata.

Problemi correlati