On Mon, Nov 15, 2010 at 06:51, Tom Eyckmans <[email protected]> wrote: > 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. >
Kind of. You can find testng that way, but testng also has a dep on JUnit (well, it's optional, but it's typically brought in) so you'd have to say the absence of testng on the cp would mean it's junit. I guess that's fine until there's another test framework that pops up. > 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 >> > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
