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

ASF GitHub Bot commented on DRILL-3589:
---------------------------------------

Github user dsbos commented on the pull request:

    https://github.com/apache/drill/pull/116#issuecomment-137811250
  
    Would it be better if the JDBC-all Jar file didn't contain a logback.xml 
file?
    
    If the JDBC-all Jar doesn't already have that file, then to configure 
logback differently with their own logback.xml file, users only have to get 
their own file on the classpath _somewhere_.
    
    However, if the JDBC-all Jar does already have that file, it seems that 
users will have to get their logback.xml file on the class path _before_ the 
JDBC-all Jar file (right?).  Although sometimes that's trivial, when the class 
path is set by, say, listing all .jar files in a lib/ directory (e.g., as in 
Tomcat for Spotfire), controlling the order might not be possible or easy.
    
    (A solution to keep the contents of the logback.xml file (as a convenient 
starting point for the user to copy out and modify) in the JDBC-all JAR file 
but not really have an active/interfering actual logback.xml file would be to 
use a modified name (e.g, logback-example.xml).)


> 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)
>             Fix For: 1.2.0
>
>
> 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