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
