1
votes

I am working towards releasing the first truly useful version of JesterJ and have hit a major snag with dependency resolution. The kind folks at Jfrog have been good enough to recognize my open source efforts with free access to Artifactory Pro and so I am using it to inspect and validate the licenses of my transitive dependencies. I use an Apache 2.0 license so I am attempting to use Apache's own standard for compliance with it's 2.0 licenses. However, one of the dependencies, Apache Tika 1.12, had some "category X" dependencies 1.12 was released around the time of some changes to that policy I think and newer versions of Tika have corrected these dependency issues.

The logical solution is to upgrade my Tika dependency. Unfortunately this has not gone well. When I upgraded Tika to 1.15 (or 1.16 now) I found that I no longer got the transitive dependencies from tika-parsers, including not getting tika-core which causes compile issues. Here's the gradle dependenccies output with 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)

And changing nothing other than the 2 to a 6 in my gradle build I get:

+--- 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)

This problem lies somewhere at the intersection of Artifactory/Gradle and may be related to the fact that Tika has begun including their pom files in META-INF in recent versions.

Things I have tried -

  1. Moving to gradle 4.0 (no change)
  2. Adding MavenCentral to my libs-release virtual repository ahead ofJCenter (no change)

I notice that the maven-central-cache repository in Artifactory does not cache the pom for 1.16 but does cache the pom for 1.12. If anyone can tell me how to get artifactory to cache/serve the pom or get gradle to ask for it properly (not sure which is the issue) that would be helpful.

Full build file configuration is visible here: https://github.com/nsoft/jesterj/blob/273c99a0bceccda7f0933299c699232fec1079ad/code/ingest/build.gradle

Anonymous access to the jetsterj artifactory here: https://jesterj.jfrog.io/jesterj/webapp/#/home

1
If you look at the Apache Tika Parser 1.16 pom on Maven central you'll see it correctly depends on Tika Core etc. Why not just tell Gradle to use Maven Central directly? - Gagravarr
Because I am using the license management features in Artifactory, which are reported in terms of "a build" and there's a couple cases where I need to provide patched versions of libraries. - Gus
I can only suggest then you report a bug to Artifactory, if you really need to use that, as it seems to be breaking things.... - Gagravarr
Starting here... bug report if I get no traction/explanation... - Gus
I am not sure how it's an Artifactory issue. Does Gradle build that goes directly to Maven Central resolve those dependencies? - JBaruch

1 Answers

2
votes

In the end I had to file a bug with JFrog. They solved it for me.

It turns out that the problem was with a setting I had enabled. There is a setting to hide unauthorized resources with a 404 instead of 401 (preventing folks from fishing around to see what you have that you are not revealing). This sounded vaguely more secure so I enabled it. I believe all was fine until I also enabled the anonymous access... This combination breaks gradle's dependency resolution. JFrog support says maven (and probably also gradle) always try anonymous access first. Upon getting 404 it probably assumes the resource (the pom.xml) doesn't exist. No pom, no dependency list.

The only thing special about Tika 1.12 was that I had already loaded it up before enabling anonymous access.

So the fix was to uncheck this setting:

screenshot of setting