Interestingly, the build passes for me with Java 8. But I'll fix the 'java' plugin so that it's not affected by the commit in question. Daz
On Fri, Jul 11, 2014 at 9:14 AM, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > Yep, I can see how this commit would have caused this problem. Although I > have no idea why building with Java 8 makes a difference. > > The underlying issue is that we've been sharing some plugin infrastructure > between the new native/jvm component plugins and the original > java/groovy/scala plugins. As the new component infrastructure becomes more > sophisticated, it's harder to make changes without breaking the original > plugins. I think the solution for now is to share less between the old and > new plugins: this has proved necessary in recent experiments with moving > the new plugins to use ModelRules. > > I'll fix this soon. > Daz > > > On Fri, Jul 11, 2014 at 4:58 AM, Perryn Fowler < > perryn.fow...@gradleware.com> wrote: > >> I discovered this when trying to set the gradle build to use the latest >> nightly. >> >> To reproduce run './gradlew clean core:check' with Java 8 >> >> What I have found so far: >> >> >> - The ide subproject uses the workaround described here( >> http://issues.gradle.org/browse/GRADLE-1190) in order to have java >> and groovy source in different dirs >> - This no longer works when building with Java 8 >> - The workaround sets the java source dirs to empty, but when using >> Java 8 they somehow get re-populated before the end of the configuration >> phase >> - according to git bisect the commit that broke this is >> >> https://github.com/gradle/gradle/commit/0cbda5ff96de182c85035988c69dbf608693c485 >> >> Pez >> > > > > -- > Darrell (Daz) DeBoer > http://www.gradleware.com > -- Darrell (Daz) DeBoer http://www.gradleware.com
