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
