An example of why we should be careful using Groovy for core plugins.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

An example of why we should be careful using Groovy for core plugins.

Luke Daley-2
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


Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Szczepan Faber-2
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.

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Luke Daley-2


On 13 Jan 2014, at 7:07, Szczepan Faber <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Szczepan Faber-2
Oh, gotcha now.


On Mon, Jan 13, 2014 at 8:14 AM, Luke Daley <[hidden email]> wrote:


On 13 Jan 2014, at 7:07, Szczepan Faber <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Jochen Theodorou
In reply to this post by Luke Daley-2
Luke,

would you say this is because of the exception style used for not
finding something?

Am 11.01.2014 14:51, schrieb Luke Daley:

> 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.
>


--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Luke Daley-2

On 13 Jan 2014, at 12:14 pm, Jochen Theodorou <[hidden email]> wrote:

> Luke,
>
> would you say this is because of the exception style used for not finding something?

There's nothing really stopping us using a custom error message in a getProperty() implementation and perhaps using a custom MissingPropertyException, so I don't think so.

>
> Am 11.01.2014 14:51, schrieb Luke Daley:
>> 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.
>>
>
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Jochen Theodorou
Am 13.01.2014 21:04, schrieb Luke Daley:
>
> On 13 Jan 2014, at 12:14 pm, Jochen Theodorou <[hidden email]> wrote:
>
>> Luke,
>>
>> would you say this is because of the exception style used for not finding something?
>
> There's nothing really stopping us using a custom error message in a getProperty() implementation and perhaps using a custom MissingPropertyException, so I don't think so.

but then I must say I don't get this thread. Sure, if you would do this
in Java, you would do this different and then get another message.
Probably you are forced to make one. And if you are forced to make one,
you will of course ensure a better one.... but here you are practically
forced too and blame instead the property runtime finding logic. Sure,
no bashing. Still I kind of don't see the point you are trying to make
anymore now.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

erdi
I personally understand it like this: we depend to much on property finding logic in groovy which then makes error messages obscure for core plugin users. We should change the way we code this kind of things so that the error messages are more expressive when stuff isn't found by:
- not using dynamic properties so much and ensuring that stuff being referenced is there
- using java which will force us to do what's mentioned in the previous point

There is no bashing. It's just pointing out that using this mechanism isn't quite fit for this purpose.



On Wed, Jan 15, 2014 at 8:40 AM, Jochen Theodorou <[hidden email]> wrote:
Am 13.01.2014 21:04, schrieb Luke Daley:


On 13 Jan 2014, at 12:14 pm, Jochen Theodorou <[hidden email]> wrote:

Luke,

would you say this is because of the exception style used for not finding something?

There's nothing really stopping us using a custom error message in a getProperty() implementation and perhaps using a custom MissingPropertyException, so I don't think so.

but then I must say I don't get this thread. Sure, if you would do this in Java, you would do this different and then get another message. Probably you are forced to make one. And if you are forced to make one, you will of course ensure a better one.... but here you are practically forced too and blame instead the property runtime finding logic. Sure, no bashing. Still I kind of don't see the point you are trying to make anymore now.

bye blackdrag


--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: An example of why we should be careful using Groovy for core plugins.

Luke Daley-2
In reply to this post by Jochen Theodorou


> On 15 Jan 2014, at 8:40, Jochen Theodorou <[hidden email]> wrote:
>
> Am 13.01.2014 21:04, schrieb Luke Daley:
>>
>> On 13 Jan 2014, at 12:14 pm, Jochen Theodorou <[hidden email]> wrote:
>>
>>> Luke,
>>>
>>> would you say this is because of the exception style used for not finding something?
>>
>> There's nothing really stopping us using a custom error message in a getProperty() implementation and perhaps using a custom MissingPropertyException, so I don't think so.
>
> but then I must say I don't get this thread. Sure, if you would do this in Java, you would do this different and then get another message. Probably you are forced to make one. And if you are forced to make one, you will of course ensure a better one.... but here you are practically forced too and blame instead the property runtime finding logic. Sure, no bashing. Still I kind of don't see the point you are trying to make anymore now.

It's about explicitness and the better error messages that can be provided through explicitness.

tasks.al

Did that person mistype "all" (i.e. getAll())? Or are they expecting a task to exist called "al"? The infrastructure can't tell so it just throws MPE with a generic messages.

tasks.taskWithName("al")

Explicit, so can produce better error.

Our internals HAVE to produce useful error messages. We allow concise forms for the outer user layer where conciseness trumps (so goes the theory).

We _could_ achieve the same using Groovy internally, but in Java there is reduced temptation to go the easy way.

>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email