Hi, You can use --<test-task>.single=xxx (so, --integTest.single for integration tests, for example).
BR, Michael -----Original Message----- From: Ioan Eugen Stan [mailto:stan.ieu...@gmail.com] Sent: Sunday, March 02, 2014 10:18 AM To: dev@gradle.codehaus.org Subject: Re: [gradle-dev] upgrade gradle to groovy 2 Hello, Thank you for all your support so far. I've started hacking on gradle with groovy 2.2.1. So far so good. No major changes required, except an upgrade for Spock to groovy2.2 version. I've pushed my changes here: https://github.com/gradle/gradle/pull/253 . I have some issues. 1. It takes an awful lot of time. I currently do: ./gradlw test ant it build all modules until it fails. I make a change and then re-run hte whole tests. How can I avoid this? In Maven I could see the project reactor in a multi-module project and build individual projects. 2. How can I run a specific test class to make sure I fixed it before running all tests. 3. I have no clue on how to fix the current failing tests so help if very appreciated. You can find the current state in the pull request. Cheers, On Thu, Feb 27, 2014 at 1:50 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote: > > On 27 Feb 2014, at 10:40 am, Ioan Eugen Stan <stan.ieu...@gmail.com> wrote: > > Hello, > > I've been watching the thread. I've cloned gradle and changed the > groovy dependency to 2.0.7 > > > We might as well jump straight to the latest Groovy 2.2.x release. > > > and got some errors: > > ---- > efaultScriptCompilationHandler.java:95: error: > visitSource(String,String) in <anonymous > org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler$1$1 > $1> cannot override visitSource(String,String) in ClassWriter > public void visitSource(String sourcePath, > String debugInfo) { > ^ overridden method is final > > > For the purposes of getting something to work, you can just comment > out that overridden visitSource(). It doesn’t do anything important (at this > stage). > > > ---- > > Forked the project, I'll try some changes when I get some free time. > > Thanks, > > > > On Wed, Feb 26, 2014 at 7:31 PM, Daz DeBoer > <darrell.deb...@gradleware.com> wrote: > > On Tue, Feb 25, 2014 at 2:42 AM, Jochen Theodorou <blackd...@gmx.org> wrote: > > > Am 24.02.2014 00:48, schrieb Daz DeBoer: > > > On Sun, Feb 23, 2014 at 3:25 AM, Ioan Eugen Stan > <stan.ieu...@gmail.com <mailto:stan.ieu...@gmail.com>> wrote: > > Hello, > > Short version question: What would it take to make gradle build with > groovy 2 - (before Debian Jessie Freeze at start of this November) ? > > > Short answer: we can't switch to Groovy 2 without breaking compiled > plugins, and we have a strict backward compatibility standard for > minor releases. > > > > > Since we haven't deprecated support for Groovy 1.8.6, it's unlikely > we'll remove support for this version in Gradle 2.0, our next major > release. > > > > your comment implies binary incompatibility. Maybe you did not mean > that, but Groovy 2 is binary compatible with even Groovy 1.0 - afaik > > What you might wanted to say is that there have been API changes. If > they are only in DefaultGroovyMethods (and friends), then gradle can > use an extension module to provide a different behaviour quite easily. > > > > Thanks for the clarification. It seems like a few members of the > Gradle team (myself included) were operating under the incorrect > assumption that there was binary incompatibility between 1.x and 2.0, > and that by moving to 2.0 _every_ plugin that was compiled against > Groovy 1.x would need to be recompiled. This was considered an > unacceptable situation, even moving to Gradle 2.0. > > If the majority of compiled plugins would continue to function even if > we changed Gradle to use Groovy 2.x, then we'd probably make the > switch for the next major version of Gradle, which will happen in the next 6 > months. > > > Imho the real question is: what would really break if you used Groovy 2? > And I get th feeling, that nobody can answer that really in any, but > one case (a change in DefaultGroovyMethods, which gradle can fix on > the gradle > side) > > > @Ioan, if you're still interested in helping out, it would be great to > know just how many things will break with a change to Groovy 2. You > could fork the Gradle project, make the change and the work on getting things > running. > @Jochen if you've got bandwidth to assist, I'm sure your Groovy > expertise would be greatly appreciated. > > cheers > Daz > > > > > -- > Ioan Eugen Stan > 0720 898 747 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, > Consulting http://www.gradleware.com > > > -- Ioan Eugen Stan 0720 898 747 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7050 - Release Date: 01/31/14 Internal Virus Database is out of date. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
