Just some outside commentary... As a community member trying to contribute,
the only name I could possibly use is the naming convention used everywhere
else in the codebase. I think everyone would admit that XYZExtension is
consistently used for all the plugins, at least it was when the pull
request was made. This conversation is clearly an strategic decision, which
should be applied on a wider scale than a single pull request. Can I
suggest that the pull request be evaluated on its code quality and any
naming strategy be applied separately in a larger context than
FindBugs? Likewise the FindBugsExtension file existed before this pull
request.
The findbugs plugin is unconfigurable at this point, making it relatively
useless without these settings, and people are asking for the
functionality. The work was done before the code quality plugins were
refactored to use specs and was then re-done using specs. Essentially I've
been working on this little required piece of functionality for ages now.
Concerning the naming, as someone not intimately familiar with the
codebase, "Extension" is a good name. Plugins and people in the community
are still migrating away from Conventions, so further naming changes would
be confusing. The name also maps extremely nicely to the method with
applies an extension:
project.extensions.create("findbugs", FindBugsExtension). Currently it's
really obvious when I see a XYZExtension class what it's for.
On Mon, Aug 20, 2012 at 1:39 AM, Szczepan Faber <
[email protected]> wrote:
> I think I understand Luke's concern, yet I have a feeling the extension
>> postfix has little actual impact on modelling.
>>
>>
>> I think it can have as much impact as any name.
>>
>
> You're right. What I meant is I'd rather model from the build, where the
> internal implementation name has little impact.
>
>> Poorly written plugin will will have week model regardless of the name
>> for the extension class.
>>
>>
>> So don't try?
>>
>
>> The extension class name is not really exposed to the build itself so the
>> biggest modelling effort is to design the DSL
>>
>>
>> People look at our codebase to see how they should be doing things.
>> That's where the naming comes into play.
>>
>> (i.e. the methods/properites/nested types on the extension object). I
>> would expect the meaty plugin logic to implemented outside of the extension
>> class, leaving the extension object only responsible for the build dsl
>> (that is 'extending' it... ;).
>>
>> Capturing the context in which the class is used in the class' name
>> sometimes makes the codebase easier to grasp. Hence I don't think Extension
>> postfix is such a bad thing.
>>
>>
>> So are we saying that in every case what gets injected into the build
>> language should be some kind of facade or adapter? Or are we saying that
>> unless it's describing something more tangible in the domain (e.g. source
>> set, custom packaging) it should be an “extension”?
>>
>> Anyway… I'm not going to pursue this issue any further.
>>
>>
>> That's just my POV :)
>>
>> Cheers!
>>
>> On Thu, Aug 16, 2012 at 11:55 AM, Luke Daley
>> <[email protected]>wrote:
>>
>>>
>>> On 16/08/2012, at 8:43 AM, Sean Reilly wrote:
>>>
>>> If the class' purpose is to provide DSL elements, then how about naming
>>> it FindBugsDSL?
>>>
>>>
>>> That's better than extension for me.
>>>
>>>
>>> On Wed, Aug 15, 2012 at 9:16 PM, Adam Murdoch <
>>> [email protected]> wrote:
>>>
>>>>
>>>> On 15/08/2012, at 11:04 PM, Luke Daley wrote:
>>>>
>>>> I think we should avoid doing this.
>>>>
>>>> My issue with it is that it's weak modelling. Not to pick on FindBugs
>>>> (it's by far not the only plugin that does this, including my own), but
>>>> what's the role of a class named “FindBugsExtension”?
>>>>
>>>> These things have a purpose or function, and the name should reflect
>>>> it. The fact that it's a build language extension is not really relevant to
>>>> its name I don't think.
>>>>
>>>>
>>>> But that's exactly it's purpose. Every plugin has an extension object
>>>> that wires in the DSL for that plugin. It's just a container for a set of
>>>> DSL elements for that plugin. That's all it is, the entire reason for its
>>>> existence. Certainly, each particular element of the plugin's DSL has
>>>> individual purpose, and should be typed and modelled and named according to
>>>> it's purpose. No question there.
>>>>
>>>> The fact that the FindBugs DSL currently only contains properties that
>>>> define some default values is a coincidence. We might later add, say, some
>>>> ruleset definitions. These aren't defaults - they're a model. So,
>>>> FindBugsDefaults would have to be renamed back to FindBugsExtension.
>>>>
>>>> These things are DSL extensions.
>>>>
>>>>
>>>> --
>>>> Adam Murdoch
>>>> Gradle Co-founder
>>>> http://www.gradle.org
>>>> VP of Engineering, Gradleware Inc. - Gradle Training,
>>>> Support, Consulting
>>>> http://www.gradleware.com
>>>>
>>>>
>>>
>>> --
>>> Luke Daley
>>> Principal Engineer, Gradleware
>>> http://gradleware.com
>>>
>>>
>>
>>
>> --
>> Szczepan Faber
>> Principal engineer@gradleware
>> Lead@mockito
>>
>>
>> --
>> Luke Daley
>> Principal Engineer, Gradleware
>> http://gradleware.com
>>
>>
>
>
> --
> Szczepan Faber
> Principal engineer@gradleware
> Lead@mockito
>
