Uploaded image for project: 'Apache Drill'
  1. Apache Drill
  2. DRILL-7529

Building depends on poorly configured uncommon maven repositories



    • Type: Bug
    • Status: Resolved
    • Priority: Trivial
    • Resolution: Duplicate
    • Affects Version/s: 1.17.0
    • Fix Version/s: 1.18.0
    • Component/s: Tools, Build & Test
    • Labels:


      Summary: Apache Drill depends on modified copies of open software that is hosted on non-standard (company owned) maven repositories. In addition due to poor security configuration maven simply refuses to download the artifacts from one of those.
      That is why I tagged this a blocker.


      I have an open source project where I include a Drill UDF so other can use this in Drill. ( https://yauaa.basjes.nl/UDF-ApacheDrill.html ).

      Today I tried to update the drill dependency from 1.16 to 1.17

      Resulting in 

      [ERROR] Failed to execute goal on project yauaa-drill: Could not resolve dependencies for project nl.basjes.parse.useragent:yauaa-drill:jar:5.15-SNAPSHOT: The following artifacts could not be resolved: com.github.vvysotskyi.drill-calcite:calcite-core:jar:1.20.0-drill-r2, org.kohsuke:libpam4j:jar:1.8-rev2: Failure to find com.github.vvysotskyi.drill-calcite:calcite-core:jar:1.20.0-drill-r2 in https://oss.sonatype.org/content/repositories/snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of Sonatype snapshots has elapsed or updates are forced -> [Help 1]

      Turns out that com.github.vvysotskyi.drill-calcite:calcite-core:jar:1.20.0-drill-r2 is (most likely) based here https://github.com/vvysotskyi/drill-calcite/

      Apparently this is a patched version of Calcite that is hosted under a personal account but IS an important dependency of a released version of Drill. (Side question: Why not simply improve calcite with these changes?)

      It took some digging and I found this one on this non standard maven repository operated by a commercial company:



      The second dependency it failed over was even worse. 


      This project IS present in maven central but NOT this specific version.


      The only place I have found this is here


      I did not encounter the sourcecode "github" for this modified version yet.

      So effectively I was forced to include two "company" repos in my project to get it to build ... so you would think.


      With these two in my pom.xml I got a new error which was much more disturbing...

      [ERROR] Failed to execute goal on project yauaa-drill: Could not resolve dependencies for project nl.basjes.parse.useragent:yauaa-drill:jar:5.15-SNAPSHOT: Failed to collect dependencies at org.apache.drill.exec:drill-java-exec:jar:1.17.0 -> org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to MapR (https://repository.mapr.com/nexus/content/groups/mapr-public/): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1]

      This error essentially means: Maven does not trust the certificate path of the provided HTTPS so it refused to download the artifact.

      Why? This MapR site uses a wildcard certificate issues by GoDaddy.

      Apparently this is a "well known" problem with these GoDaddy certificates: https://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/






          Issue Links



              • Assignee:
                nielsbasjes Niels Basjes
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: