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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809091#comment-16809091 ] 

ASF subversion and git services commented on GEODE-6383:
--------------------------------------------------------

Commit 203aac1962af289b461962ffc3b290b2d11e9717 in geode's branch refs/heads/develop from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=203aac1 ]

GEODE-6400: Enable third-parties to consume Geode via Gradle composite build.

* Expose geode-assembly configuration compositeTarget to allow tgz
consumption via 'targetConfiguration' in dependency declarations.
* Explicitly chain root tasks to subprojects: clean, check, test
* Multiple improvements using deferred initialization of task objects.
* Proper task-input specification
* Use of CopySpec objects for modularity/reuse and readability of
distribution contents
* Extract 'checkPom' tasks to its own gradle file for inclusion with out
publish.gradle
* Update dependency declarations and comments
* `geode-assembly` is not a Java project, does not depend on a BOM, and
should not be configured by publish.gradle.  Extraction of
publish.gradle to not be invasive belongs to future work GEODE-6383.

Co-authored-by: Patrick Rhomberg <pr...@pivotal.io>
Co-authored-by: Robert Houghton <rh...@pivotal.io>


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