Can't we can make the distinction between first level dependencies so you we should be able to figure it out that way.
2010/11/15 Jason Porter <[email protected]> > 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 > > >
