>From the discussion It seems to me that the the idea of having to apply plugin for test frameworks was in general accepted. Yet I can not see a JIRA issue for this. Should I create one?
-- Regards / Pozdrawiam Tomek Kaczanowski 2010/10/6 John Murph <[email protected]>: > 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. > > Anyway, interesting ideas. > > -- > John Murph > Automated Logic Research Team > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
