Do you see the antrun running in the maven log before the failsafe plugin? On Sep 17, 2015 12:49 PM, "Chris Westin" <[email protected]> wrote:
> 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 <[email protected]> > 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 <[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 > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
