Grad nicht auflösende transitive Abhängigkeiten für Tika über Artefakt

Question

Ich arbeite auf die Freigabe der ersten wirklich nützliche Version JesterJ und habe einen großen Haken mit Abhängigkeitsauflösung getroffen. Die freundlichen Leute bei Jfrog waren gut genug, um meine Open-Source-Bemühungen mit freiem Zugang zu Artifactory Pro zu erkennen und nutze sie, um die Lizenzen meiner transitiven Abhängigkeiten zu prüfen und zu validieren. Ich benutze eine Apache 2.0 Lizenz, also versuche ich Apache's own standard für die Einhaltung der 2.0 Lizenzen zu verwenden. Eine der Abhängigkeiten, Apache Tika 1.12, hatte einige Abhängigkeiten der "Kategorie X" 1.12 wurde veröffentlicht, als einige Änderungen an dieser Richtlinie vorgenommen wurden, und neuere Versionen von Tika haben diese Abhängigkeitsprobleme korrigiert.

Die logische Lösung besteht darin, meine Tika-Abhängigkeit zu aktualisieren. Leider ist das nicht gut gegangen. Als ich Tika auf 1.15 (oder 1.16 jetzt) ​​hochstufte, fand ich, dass ich die transitiven Abhängigkeiten von Tika-Parsern nicht mehr bekam, einschließlich Tika-Core nicht zu bekommen, was Kompilierungsprobleme verursacht. Hier ist die gradle dependenccies Ausgabe mit 1.12:

+--- org.apache.tika:tika-parsers:1.12 
| +--- org.apache.tika:tika-core:1.12 
| +--- org.gagravarr:vorbis-java-tika:0.6 
| | \--- org.apache.tika:tika-core:1.5 -> 1.12 
| +--- com.healthmarketscience.jackcess:jackcess:2.1.2 
| | +--- commons-lang:commons-lang:2.6 
| | \--- commons-logging:commons-logging:1.1.3 -> 1.2 
(etc) 

und ändert nichts anderes als die 2 ein 6 in meinem gradle Build ich:

+--- org.apache.tika:tika-parsers:1.16 
+--- org.apache.solr:solr-solrj:5.5.0 
| +--- commons-io:commons-io:2.4 
| +--- org.apache.httpcomponents:httpclient:4.4.1 
| | +--- org.apache.httpcomponents:httpcore:4.4.1 
(etc) 

Dieses Problem liegt irgendwo an der Kreuzung des Artifactory/Gradle und könnte mit der Tatsache zusammenhängen, dass Tika begonnen hat, ihre Pom-Dateien in META-INF in neueren Versionen aufzunehmen.

Dinge, die ich habe versucht -

1. Umzug 4.0 (keine Änderung)
2. Hinzufügen MavenCentral meiner libs-Release virtuellen Repository Gradle voraus ofJCenter (keine Änderung)

Ich stelle fest, dass Das Maven-Central-Cache-Repository in Artifactory speichert den Pom nicht für 1.16, sondern speichert den Pom für 1.12. Wenn mir irgendjemand sagen kann, wie man Artefakte bekommt, um den Pom zu cachen/zu servieren, oder ob ich mich danach sehne, danach zu fragen (nicht sicher, welches das Problem ist), wäre das hilfreich.

Voll Build-Datei Konfiguration ist hier sichtbar: https://github.com/nsoft/jesterj/blob/273c99a0bceccda7f0933299c699232fec1079ad/code/ingest/build.gradle

anonymen Zugriff auf die jetsterj artifactory hier: https://jesterj.jfrog.io/jesterj/webapp/#/home

Answer 1

Am Ende habe ich mit JFrog einen Fehler anmelden musste. Sie haben es für mich gelöst.

Es stellt sich heraus, dass das Problem mit einer Einstellung war, die ich aktiviert hatte. Es gibt eine Einstellung, um nicht autorisierte Ressourcen mit einem 404 anstelle von 401 zu verstecken (verhindert, dass Leute herumfischen, um zu sehen, was Sie haben, was Sie nicht preisgeben). Das klang vage sicherer, also habe ich es aktiviert. Ich glaube, alles war in Ordnung, bis ich auch den anonymen Zugriff aktiviert habe ... Diese Kombination bricht die Abhängigkeitsauflösung von Gradle. JFrog-Support sagt Maven (und wahrscheinlich auch Groß- und Kleinschreibung) versuchen immer anonymen Zugang zuerst. Bei 404 wird davon ausgegangen, dass die Ressource (pom.xml) nicht existiert. Keine Pom, keine Abhängigkeitsliste.

Das einzige Besondere an Tika 1.12 war, dass ich es bereits geladen hatte, bevor ich den anonymen Zugriff ermöglichte.

So war die Verlegenheit, diese Einstellung zu deaktivieren: