You can run a remote debugging session. However, given what you're describing, it sounds very much like an issue with the build rather than an issue with the Drill code or test. (Although a better error message would be nice for the situation where the app.class.path is missing.) As such, you would most likely need to debug the maven code to find out why the directive described below is failing.
It seems like, on your system, maven-antrun-plugin isn't working correctly. The use of it in this module is very simple: generate a complete classpath and then put that classpath in an environment variable. In the plugin definition we're assigning the app.class.path variable the value of the value that the antrun plugin generated for the value of maven.test.classpath. (Note that you can't use this directly as this is something that is created by the antrun plugin and isn't generally available as a property inside of maven.) The code is here: https://github.com/apache/drill/blob/master/exec/jdbc-all/pom.xml#L215 My guess is that your maven has a slightly different version of ant plugin that isn't handling this correctly. If that is the case, we can fix this by specifying a managed version of the antrun plugin. I'm on Maven 3.3.3 so when I run 'mvn help:effective-pom' and find the antrun plugin I see: <plugin> <artifactId>maven-antrun-plugin</artifactId> <version>1.7</version> </plugin> Can you confirm what you see? If you add <version>1.7</version> directly after line 215, does that resolve the issue? -- Jacques Nadeau CTO and Co-Founder, Dremio On Wed, Sep 16, 2015 at 6:17 AM, Chris Westin <[email protected]> wrote: > I only tried to run it from the IDE after it failed in mvn install (in > order to figure out why it's failing). Great, so if it can't work in the > IDE, how do we figure out why it's failing? > On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <[email protected]> wrote: > > > Ah, you're focused on testing from within the IDE? > > > > The level complexity of the build process to get a test to correctly test > > the right thing means jumping through a bunch of hoops to clear the > > classpath and then use a special classloader. I can't imagine that you > > could get it to run correctly in an ide. For example, Eclipse is very > > sloppy about keeping classpaths perfect versus what is declared in the > pom > > file. > > > > The parameter you're looking for is generated by the ant plugin simply > > because that appears the way to get the value into an environment > variable > > so that the inner classloader can load the drillbit for the test. > > > > The test: loads a drillbit in one classloader using the alternative > > classpath provided by the app.class.path variable. This is taken from > what > > would have typically been the jvm level classpath. We then clear the jvm > > classpath to only include the test class, Junit and hamcrest. After the > > drillbit is initialized and we've run one query, we then add the jdbc > all > > jar to the system classloader and open a connection to the drillbit and > > execute a query. The test is designed specifically to confirm that the > > requisite classes are correctly included in jdbc-all and that it will run > > correctly. The test can't run without the shaded jar being generated and > I > > can't imagine any of the of the ides have good enough understanding of > the > > various maven plugins and options used that they would correctly work. > Even > > if you found some changes that made the test execute in and ide, I can't > > imagine that it would correctly manage all the classpath stuff. > > On Sep 15, 2015 9:37 PM, "Chris Westin" <[email protected]> wrote: > > > > > Variability: for me so far 2 out of 2 times. > > > > > > No stack trace, but as above, when I try to reproduce it in an IDE > > > "This seems to be because the test is getting an ExceptionInInitializer > > in > > > DrillbitClassLoader because the app.class.path property isn't set (and > > then > > > the resulting String.length() on its value throws an NPE)." > > > > > > I don't see app.class.path set anywhere in any pom.xml (so it's not > > getting > > > set when I copy the surefire arguments into the IDE's launch > > configuration > > > for the test, either). > > > > > > > > > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <[email protected]> > > > wrote: > > > > > > > It was tested on a clean machine a number of times. Any thoughts on > the > > > > variability? Can you provide stack trace? > > > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <[email protected]> > > wrote: > > > > > > > > > Yes, I see this issue too. > > > > > > > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > This seems to be because the test is getting an > > > ExceptionInInitializer > > > > in > > > > > > DrillbitClassLoader because the app.class.path property isn't set > > > (and > > > > > then > > > > > > the resulting String.length() on its value throws an NPE). > > > > > > > > > > > > Bueller? > > > > > > > > > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin < > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > >> I just rebased, and twice in a row I've gotten wedged running > > > > > >> org.apache.drill.jdbc.ITTestShadedJar > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
