[ 
https://issues.apache.org/jira/browse/DRILL-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649690#comment-14649690
 ] 

Jacques Nadeau commented on DRILL-3589:
---------------------------------------

We also have the jdbc-all artifact, whose goal is to be the minimal class set 
required for function.  You could possibly try that artifact.  Note that the 
one issue there is that we don't shade the encapsulated classes so you may 
still hit your guava issue.

> JDBC driver maven artifact includes a lot of unnecessary dependencies
> ---------------------------------------------------------------------
>
>                 Key: DRILL-3589
>                 URL: https://issues.apache.org/jira/browse/DRILL-3589
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Client - JDBC
>            Reporter: Joseph Barefoot
>            Assignee: Daniel Barclay (Drill)
>            Priority: Minor
>
> The Drill JDBC POM file pulls in so many unused transitive dependencies that 
> it takes quite a while to exclude all the unnecessary ones when using it from 
> within a Java project.  This is similar to DRILL-3581 in that you can work 
> around it via exclusions of transitive dependencies, but since it makes 
> interoperability with other open-source projects problematic, this will keep 
> coming up for anyone using the JDBC driver from within any serious java app.
> Considering the pom:
> http://repo1.maven.org/maven2/org/apache/drill/exec/drill-jdbc/1.1.0/drill-jdbc-1.1.0.pom
> ...it seems that most of the unused dependencies are transitive from 
> drill-common and perhaps also drill-java-exec.  Here's an example of some 
> dependencies that the JDBC driver shouldn't need (and we excluded in our 
> project):
> parquet-*
> jetty-server
> javassist
> commons-daemon
> hibernate-validator
> xalan
> xercesImpl
> For the record we are now able to use the JDBC driver fine from within our 
> project, but it did take some dependency tree analysis (and a little 
> trial-and-error) to figure out what to exclude.  We would like to save future 
> developers that time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to