> 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
