[
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}
This is particularly problematic when certain plugins or built-ins do not
integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing to
be applied before the {{java}} plugin.
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, such as the work done in
GEODE-6237.
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, such as the work done in
GEODE-6237.
> 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}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> 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, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
