Das OSS-Lizenz-Plugin enthält keine Lizenzen für das Bibliotheksmodul

9

Nach der Migration auf Android-Plug-in für Gradle 3.0 enthält das OSS-Lizenz-Plugin ( Ссылка ) die Lizenzen nicht mehr Abhängigkeiten der Bibliotheksmodule des Projekts. Nur das "App" -Modul.

Ich verwende com.google.gms:oss-licenses:0.9.1 und com.google.android.gms:play-services-oss-licenses:11.8.0

Wenn ich das Plugin auf alle meine Module anwende, werden die third_party_license -Daten im rohen Ordner für jedes Modul generiert. Aber am Ende landen nur die Daten aus dem App-Modul in der APK.

Gibt es eine Problemumgehung für dieses Problem?

    
Petrus 28.01.2018, 15:57
quelle

1 Antwort

0

Ja, das ist richtig.

Basierend auf meiner Suche, wie das Plugin funktioniert, würde das Plugin die Daten im res/raw Ordner des Artefakts ( aar oder apk , aber nicht jar Dateien) basierend auf POM Dateien erzeugen es kann von den Bibliotheken kommen. Der Rest der Zusammenführung erfolgt dann über Gradle Android Plugin und nicht über das OSS License Plugin, das die res Ordner aus allen Quellen (Abhängigkeits-Bibliotheken, Module, Haupt-App usw.) zusammenführt. Allerdings ist hier das Problem, dass das Android Gradle Plugin bei der Zusammenführung eines auswählen würde, wenn es Duplikate derselben Ressource gibt ( link zur Erklärung), und die gewählte basiert auf einer Priorität, was bedeutet, dass sowohl das App-Modul als auch das lib-Modul die R.raw.third_party_license -Ressource erzeugen, die Duplikate sind, die aus der App Das Modul hat eine höhere Priorität als das Modul, daher sind die Lizenzinformationen aus dem Modul nicht enthalten.

Es gibt mehrere Möglichkeiten, dies zu beheben:

  1. Fügen Sie die gleichen Abhängigkeiten von Ihrem Bibliotheksmodul in Ihr App-Modul ein. Dies ist wahrscheinlich die schlechteste Idee, aber es hat keinen Einfluss auf Ihre App, da Gradle automatisch die Abhängigkeiten ohne Probleme auflösen würde, insbesondere wenn sie die gleiche Version haben. Wenn sie unterschiedliche Versionen hätten, würde Gradle das Neueste wählen. li>
  2. Anstatt eine Modulabhängigkeit zu verwenden, veröffentlichen Sie das Modul in einem maven Repo (lokal oder remote, hier ist ein link , um zu zeigen, wie es lokal gemacht werden könnte, und füge seine Abhängigkeit als solche hinzu: implementation 'com.mygroup:library:1.0' . Vergessen Sie nicht, es aus der Datei build.settings des Projekts zu entfernen. Dies würde die POM -Datei des Bibliotheksmoduls erzeugen und somit das Plugin dazu bringen, es zu lesen und seine Bibliothekslizenzen einzuschließen. Dies bedeutet, dass die Bibliothek kompiliert und veröffentlicht werden sollte, bevor das App-Modul kompiliert wird. Es kann aber auch zu seltsamen Kompilierungsproblemen kommen, wenn Fehler auftreten.

Leider gibt es einen weiteren Weg, von dem ich dachte, dass er funktionieren würde, aber nicht. Dies geschieht, indem Sie die Abhängigkeiten in Ihrem Bibliotheksmodul in api anstelle von implementation ändern. Dadurch würden die Bibliotheksabhängigkeiten den Abhängigkeiten des Anwendungsmoduls ausgesetzt, die Build-Zeit des Projekts jedoch erhöht. Aber schließlich hat es die rohen Ressourcen nicht richtig generiert, da das OSS-Lizenz-Plugin anscheinend nur die Abhängigkeiten von einer POM-Datei der Bibliothek liest und in diesem Fall die POM -Datei nicht erzeugt wird, selbst wenn die Abhängigkeiten des Bibliotheksmoduls offengelegt wurden . Wahrscheinlich sollte dies als Enhancement- oder Bug-Anfrage an die Entwickler des Plugins posten.

    
ahasbini 08.02.2018 11:33
quelle

Tags und Links