I upgraded to maven 3.3.3 (from 3.2.3). I checked effective pom, and it's antrun 1.7. However, the unit tests still get wedged in the same place.
On Wed, Sep 16, 2015 at 8:05 AM, Jacques Nadeau <jacq...@dremio.com> wrote: > 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 <chriswesti...@gmail.com> > 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" <jacq...@dremio.com> 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" <chriswesti...@gmail.com> > 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 <jacq...@dremio.com> > > > > 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" <skat...@maprtech.com> > > > wrote: > > > > > > > > > > > Yes, I see this issue too. > > > > > > > > > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin < > > chriswesti...@gmail.com > > > > > > > > > > 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 < > > > > chriswesti...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> I just rebased, and twice in a row I've gotten wedged running > > > > > > >> org.apache.drill.jdbc.ITTestShadedJar > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
