Oh, gotcha now.
On Mon, Jan 13, 2014 at 8:14 AM, Luke Daley <luke.da...@gradleware.com>wrote: > > > On 13 Jan 2014, at 7:07, Szczepan Faber <szczepan.fa...@gradleware.com> > wrote: > > Not sure how would java help here. The problem is that we assume that root > project has idea plugin - this assumption can be coded in java or in groovy > (btw. this is a fairly sane assumption, I don't know of any use cases that > support not having idea applied to root). > > I generally agree with your conclusion, it's just I don't think this > example supports it well. > > > The error message would say that no task could be found, not that some > property could not be found on some internal type. > > > When idea plugin configures for scala it requires idea to be applied to > root (given current implementation). This requirement needs to be checked > properly and decent error presented to the user otherwise. I've hit this > issue in past, too. Time to fix this puppy ;) > > Cheers! > > > On Sat, Jan 11, 2014 at 2:51 PM, Luke Daley <luke.da...@gradleware.com>wrote: > >> Hi, >> >> I don't mean to be inflammatory by my subject. This is not an attack on >> Groovy. >> >> I just tried to upgrade a project to Gradle 1.10 and was greeted with >> this error: “Could not find property 'ideaProject' on task set.” >> >> Tracked it down to this: >> https://github.com/gradle/gradle/blob/master/subprojects/ide/src/main/groovy/org/gradle/plugins/ide/idea/IdeaPlugin.groovy#L177 >> >> “project.rootProject.tasks.ideaProject” will produce this error the IDEA >> plugin isn't applied to the root. >> >> Because of our many layers of dynamic indirection, the error messages >> when using DSL style Groovy in infrastructure can be not very clear. This >> isn't Groovy's fault. It's that using Groovy in our infrastructure makes it >> tempting to go the shortest (untyped) path and this is susceptible to >> obtuse error messages and bad user experiences. If we'd used Java in _this_ >> particular instance we'd have had a better error message. >> >> Granted that we should also strive to make the error messages better for >> DSL users so there's a balance here of course. For core infrastructure >> though, I'm for us taking on the pain of writing in Java if it helps the >> user through better error reporting. >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > -- > Szczepan Faber > Principal engineer@gradle; Founder@mockito > > -- Szczepan Faber Principal engineer@gradle; Founder@mockito
