2009/11/14 Ali, Haneef <[email protected]>

> Hi,
>
> I have test extending from GroovyLogTestCase.  This test class is not
> detected by JunitTestDetecter. Most probably it is a defect in the code. I
> believe it should be instanceOf instead of equals
>
> From JUnitDetector.java
>    else if ( "junit/frameworkTestCase".equals(superClassName) ||
> "groovy/util/GroovyTestCase".equals(superClassName) ) {
>                isTest = true;
>

The cause of this class not being picked up by the test class detection is
because the GroovyLogTestCase is in the groovy.lang package, currently the
test detection assumes that there is no need to scan into java.lang and
groovy.lang. As this appears to be an incorrect assumption I'll remove it
and make it so that we scan as far up as possible without package
short-circuit checks.

>
>
> Is there a work around to include my test class?
>

In case you use a naming convention like *Test you can disable test class
scanning and use the filename matching by disabling the test class detection
by setting scanForTestClasses to false:

test {
    scanForTestClasses = false
}

>
> Thanks
> Haneef
>
>
>
> -----Original Message-----
> From: Roger Studner [mailto:[email protected]]
> Sent: Friday, November 13, 2009 5:37 PM
> To: [email protected]
> Subject: Re: [gradle-user] Compilation Destination
>
> Thanks.
>
> I guess this perfectly hi-lights the actual issue with the gradle docs.
>
> This, is buried in a "show" task example, talking about the "conventions"
> object.
>
> Even the syntax (sourceSets.main.classesDir)
>
> Where as in the Source Sets section (yes, only a a couple pages further
> down) the only syntax examples are like this:
> sourceSets {
>    main {
>        java {
>            srcDir 'src/java'
>        }
>        resources {
>            srcDir 'src/resources'
>        }
>    }
> }
>
> Clearly, with familiarity, all of this begins to link together great.  But
> from a *new* Gradle users POV, it is nearly impenetrable heh.
>
> As I get better at this, i'm going to do my best to post post post and help
> write docs all I can.
>
> I did notice in nabble or another "Q&A place" that someone was begging to
> have a lot of these configuration options consolidated... maybe a gradle
> command that just outputs ALL the defaults would help (and be a very short
> path to helping with that effort).
>
> Again, thanks very much for you answer!  The communities are what make
> these projects amazing :)
>
> Roger
>
> On Nov 13, 2009, at 4:29 PM, Steve Ebersole wrote:
>
> > The SourceSet itself has a r/w classesDir property.  The classesDir
> > would appear to default to 'classes/%s' where '%s' is the name of the
> > sourceSet.
> >
> > So for example:
> > sourceSets.main.classesDir = new File(buildDir, 'output')
> >
> > ^^ taken verbatim from the user guide btw
> >
> >
> >
> > On Fri, 2009-11-13 at 16:14 -0500, Roger Studner wrote:
> >> I've noticed that I can change buildDirName to anything I want.
> >>
> >> But inside of it, it is always:
> >>
> >> classes/main/<my stuff>
> >>
> >> how can I change the "classes/main"
> >>
> >> I'm trying to get gradle & gwt to play nice.. i've seen plenty of blog
> posts on it, but outside of their academic nature, none of them actually
> "work" for GWT 1.6+ in terms of leaving someone with the ability to run
> hosted mode etc.
> >>
> >> I'm just trying to get this all shored up enough, so that it 100% works
> and I can share the knowledge :)
> >>
> >> Roger
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >>    http://xircles.codehaus.org/manage_email
> >>
> >>
> > --
> > Steve Ebersole <[email protected]>
> > Hibernate.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

Reply via email to