Skip to content

Gradle Improvements #475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 18, 2018
Merged

Gradle Improvements #475

merged 1 commit into from
Mar 18, 2018

Conversation

nebhale
Copy link
Member

@nebhale nebhale commented Mar 16, 2018

This change contributes some improvements to the Gradle build.

The most significant change is the introduction of the io.spring.dependency-management plugin. Don't let the name fool you, while this plugin was created for the Spring teams, it's generally applicable for all users of Gradle. This plugin allows you to define a dependencyManagement section (equivalent of the Maven construct of the same name). The information about the dependencies in
that section is then used by each subproject to include dependencies without needing to specify a version number. This solves the problem of keeping groups of dependencies in sync with one another across projects and centralizes all the versions into a single location that can be quickly updated when necessary.

dependencyManagement {
  dependencies {
    dependency 'junit:junit:4.12'
  }
}
dependencies {
  testImplementation 'junit:junit'
}

The second important change is the update of projects so that they now use the Gradle java-library plugin instead of the java plugin. This plugin is more modern, is considered idiomatic and allows much more control of the dependencies that a library exposes in it's POM as compile-time dependencies.

Next, the build now minimizes the collection of artifacts that are published to Artifactory and Bintray repositories. Specifically, it ensures that the rsocket-examples and rsocket-test JARs are not published with the rest of the globally useful artifacts.

The Artifactory and Bintray configurations have been split out into separate build scripts. This modularity encapsulates each publishing location's configuration and isolates it from the other. It also has the side-benefit of removing noise from the main build script which is much more focused on
compiling code and creating JARs. At this time, I'm pretty confident in the configuration of the Artifactory, Bintray, and Maven Central configurations, but only actual publication to each will be able to verify that there were no regressions.

Finally, dependencies were updated and Gradle configuration was streamlined (removing redundant declaration of defaults) to generally speed up and shrink the build.

This change contributes some improvements to the Gradle build.

The most significant change is the introduction of the io.spring.dependency-
management plugin.  Don't let the name fool you, while this plugin was created
for the Spring teams, it's generally applicable for all users of Gradle.  This
plugin allows you to define a dependencyManagement section (equivalent of the
Maven construct of the same name).  The information about the dependencies in
that section is then used by each subproject to include dependencies without
needing to specify a version number.  This solves the problem of keeping
groups of dependencies in sync with one another across projects and
centralizes all the versions into a single location that can be quickly
updated when necessary.

dependencyManagement {
  dependencies {
    dependency 'junit:junit:4.12'
  }
}

dependencies {
  testImplementation 'junit:junit'
}

The second important change is the update of projects so that they now use the
Gradle 'java-library' plugin instead of the 'java' plugin.  This plugin is
more modern, is considered idiomatic and allows much more control of the
dependencies that a library exposes in it's POM as compile-time dependencies.

Next, the build now minimizes the collection of artifacts that are published
to Artifactory and Bintray repositories.  Specifically, it ensures that the
'rsocket-examples' and 'rsocket-test' JARs are not published with the rest of
the globally useful artifacts.

The Artifactory and Bintray configurations have been split out into separate
build scripts.  This modularity encapsulates each publishing location's
configuration and isolates it from the other.  It also has the side-benefit of
removing noise from the main build script which is much more focused on
compiling code and creating JARs.  At this time, I'm pretty confident in the
configuration of the Artifactory, Bintray, and Maven Central configurations,
but only actual publication to each will be able to verify that there were no
regressions.

Finally, dependencies were updated and Gradle configuration was streamlined
(removing redundant declaration of defaults) to generally speed up and shrink
the build.
@robertroeser
Copy link
Member

LGTM

@robertroeser robertroeser merged commit b368cac into rsocket:1.0.x Mar 18, 2018
@nebhale nebhale deleted the gradle branch March 18, 2018 14:43
@nebhale nebhale mentioned this pull request Mar 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants