Questions on Groovy plugin and Test task

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions on Groovy plugin and Test task

Peter Niederwieser
1. I'd like my build to compile both .java and .groovy files under /src/main/groovy, but without the stub generation that's normally done for joint compilation. Is this possible?

2. When a JUnit 4 test throws an AssertionError, a failure is reported (as expected). But when a test throws a subclass of AssertionError (which JUnit itself does on occasion, and other JUnit runners might also do), an error is reported! Any ideas how to fix this? (I suppose this is a flaw in Ant's JUnit task.)

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: Questions on Groovy plugin and Test task

hans_d
Administrator

On May 10, 2008, at 1:48 AM, Peter Niederwieser wrote:

1. I'd like my build to compile both .java and .groovy files under
/src/main/groovy, but without the stub generation that's normally done for
joint compilation. Is this possible?

I'm not exactly sure what you want to achieve so I don't know if this information is helpful.

The Compile task of a groovy project contains two actions. One ant javac and one ant groovyc action. The ant javac action is per default applied to the  src/main/java dir. You could change this by adding:

srcDirNames << 'src/main/groovy'

Gradle always add a javac node to the groovyc task declaration. This might be the trigger for java stub generation at least for 1.5.5+. 

I don't know if you can do real joint compilation (java and groovy classes referring to each other) without stub generation.  


2. When a JUnit 4 test throws an AssertionError, a failure is reported (as
expected). But when a test throws a subclass of AssertionError (which JUnit
itself does on occasion, and other JUnit runners might also do), an error is
reported! Any ideas how to fix this? (I suppose this is a flaw in Ant's
JUnit task.)

Right. As we delegate to the Junit task there is no straight fix.

Gradle is using the Ant tasks in many places under the hood as they offer a fast and reasonable solution. But they also impose an inflexibility. There is no reason why we could not rewrite the Gradle Test  task to directly use the Junit test runner. This would also allow for a nice API where we could ask the Test task for a list of failing tests for example.  Reimplementing this is all a question of priorities and resources. I hope that rather sooner than later contributions come for this kind of stuff. As writing tasks in Gradle does not involve much knowledge of the core. Basically you just need to know about two types, Task and Project. 

The reporting of the JUnit task is another thing I'm not fond of. In case of failing tests it would be handy if the names of the failing tests would be printed out at the end (vs. searching the output log for them).  

- Hans


Cheers,
Peter
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead