Niels Basjes created DRILL-7529:
-----------------------------------
Summary: Building depends on poorly configured uncommon maven
repositories
Key: DRILL-7529
URL: https://issues.apache.org/jira/browse/DRILL-7529
Project: Apache Drill
Issue Type: Bug
Components: Tools, Build & Test
Affects Versions: 1.17.0
Reporter: Niels Basjes
*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:
[https://repository.mulesoft.org/nexus/content/repositories/public/]
The second dependency it failed over was even worse.
{{org.kohsuke:libpam4j:jar:1.8-rev2}}
This project IS present in maven central but NOT this specific version.
[https://search.maven.org/artifact/org.kohsuke/libpam4j]
The only place I have found this is here
[https://repository.mapr.com/nexus/content/groups/mapr-public/]
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/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
