drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Westin <chriswesti...@gmail.com>
Subject Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Date Thu, 17 Sep 2015 19:49:17 GMT
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 <jacques@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 <chriswestin42@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" <jacques@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" <chriswestin42@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 <jacques@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" <skatkam@maprtech.com>
> > > wrote:
> > > > >
> > > > > > Yes, I see this issue too.
> > > > > >
> > > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <
> > chriswestin42@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 <
> > > > chriswestin42@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> I just rebased, and twice in a row I've gotten wedged
running
> > > > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message