You can also check the test dependencies for which test framework is on the classpath, depending on what is on there execute testng or junit.
2010/10/7 Adam Murdoch <[email protected]> > > On 07/10/2010, at 12:30 AM, John Murph wrote: > > On Tue, Oct 5, 2010 at 6:30 PM, Adam Murdoch <[email protected]> wrote: > >> >> Another approach to all this would be that the Java plugin does not add >> any test tasks at all, and that you need to apply a particular plugin to get >> unit testing: >> >> // Adds the main source set and implicitly the standard lifecycle but no >> test task >> apply plugin: 'java' >> >> // Adds in the 'junit' task plus implicitly the test source set >> apply plugin: 'junit' >> >> // Adds in the 'testng' task plus implicitly the test source set >> apply plugin: 'testng' >> >> I think I prefer this second approach, where Gradle give you the building >> blocks to compose as makes sense for your project. It's explicit and >> declarative, which is always good. >> >> The problem is that Gradle should really be able to figure this stuff out. >> Maybe we need some kind of auto-detect plugin, which extracts as much >> information out of the source as it can. There's all sorts of interesting >> information encoded in the project's source which we could harvest to >> configure the build: languages and language version, test frameworks, >> external dependencies, project dependencies, whether it is a web app, and so >> on. >> >> This way, you can choose either: Gradle figures out as much as it possibly >> can by itself and you fill in the blanks (if any), or you tell Gradle the >> entire story. >> >> > I agree with this reasoning. I like the idea that the "java" plugin would > just set up stuff for building Java code. If I want unit testing, or code > coverage, or checkstyle I should say so and in so doing say which library > (or libraries) I wish to use to do so. Sometimes multiple options are > compatible (like JUnit and TestNG) and sometimes they might not be (I would > be surprised if EMMA and Cobertura play nicely with each other). This is > also a good approach for the "modular" plugin ideas that we've talked about > (each plugin does one thing / separation of concerns). > > I also like the idea of the "figure out my project" plugin. This is what > we are doing for our project right now and it's nice, but I wouldn't want > Gradle to do it unless it was requested. For one thing, it will make the > build a little bit slower as Gradle must analyze the project structure to > figure many of these things out. Also, if might be nice to tell such a > plugin "skip checks for <blah>, I don't want that plugin". Which means that > you need to pass parameters to plugins (I think I've suggested this before; > you haven't added it already have you? If so, awesome! just let me know). > One problem with this plugin is that your project might change behavior as > new versions of Gradle are released, but I think that's what you are asking > for if you use this plugin. > > > We can probably do some caching + up-to-date checking to minimise the > performance hit. Plus with the daemon we can be doing the analysis in the > background. So there may not be any performance hit at all. There's also > some very interesting things we can do once we have the dependency > information from the source. > > Having said that, another approach might be that the plugin doesn't do the > discovery at build configuration time. Instead, it does its discovery and > updates the build script. Similar to how you manually run the 'idea' or > 'eclipse' task to synchronise the IDE projects to reflect the contents of > the build script, in this case you would manually run the discovery task to > synchronise the build script to reflect the contents of the source tree. > > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consulting > http://www.gradle.biz > >
