[jira] [Updated] (GEODE-6383) Build scripting should not violate modularity.

["Patrick Rhomberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Rhomberg updated GEODE-6383:
------------------------------------
    Description: 
In many portions of our build scripting, we use the invasive, modularity-breaking pattern of
{noformat}
subprojects {
  configureSomething
}
{noformat}

As a result, within a single subproject, it is very difficult to know (without prior experience) how the subproject is configured.

This ticket is intended to be a "parent" ticket for jobs that fall into the following categories:

* Converting a plugin-script in {{gradle/}} to a class extending {{Plugin<Project>}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by the subprojects that require the configuration.



  was:
In many portions of our build scripting, we use the invasive, modularity-breaking pattern of
{noformat}
subprojects {
  configureSomething
}
{noformat}

As a result, within a single subproject, it is very difficult to know (without prior experience) how the subproject is configured.

This ticket is intended to be a "parent" ticket for jobs that fall into the following categories:

* Converting a plugin-script in {{gradle/}} to a class extending {{Plugin<Project>}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject {[configuration]}}} calls to be "opt-in" by the subprojects that require the configuration.




> Build scripting should not violate modularity.
> ----------------------------------------------
>
>                 Key: GEODE-6383
>                 URL: https://issues.apache.org/jira/browse/GEODE-6383
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Patrick Rhomberg
>            Priority: Major
>
> In many portions of our build scripting, we use the invasive, modularity-breaking pattern of
> {noformat}
> subprojects {
>   configureSomething
> }
> {noformat}
> As a result, within a single subproject, it is very difficult to know (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending {{Plugin<Project>}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by the subprojects that require the configuration.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)