Skip to content
This repository has been archived by the owner on Dec 1, 2022. It is now read-only.

Clean up Gradle build scripts, move config to root project #287

Merged
merged 2 commits into from Nov 8, 2017
Merged

Clean up Gradle build scripts, move config to root project #287

merged 2 commits into from Nov 8, 2017

Conversation

wjbuys
Copy link
Contributor

@wjbuys wjbuys commented Nov 6, 2017

This moves as much of our repeated subproject configuration as makes sense to the root project, and versions more of the most common dependencies using dependencyManagement in the root project.

This also consolidates all plugin versions in the root project using the plugins {} block, and only applies them in subprojects that need them. In order to make use of this new syntax in more places, this also upgrades the Gradle version to 4.3 (release notes)

Licensing

This contribution is under the terms of the Apache 2.0 License: Yes

@wjbuys wjbuys self-assigned this Nov 6, 2017
The new version of gradle fixes some issues with the new `plugins`
directive. In particular, it's now possible to use it to activate
plugins in subprojects that have already been declared in the root
project.
classpath 'com.diffplug.gradle.spotless:spotless:2.4.1'
dependencyManagement {
imports {
mavenBom 'com.amazonaws:aws-java-sdk-bom:1.11.215'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need both sdk version or is this so we don't have to refactor code that doesn't use v2 now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is so that we don't have to refactor the parts of the dataservice that still depend on V1 now.

@@ -20,6 +22,7 @@ dependencies {
exclude group: 'com.github.jknack', module: 'handlebars'
}

// We can't rely on the dependency-managed version of lombok here, so we have to hardcode it:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The buildSrc special project is built before the main project, and so it can't get any configuration from the main project. I'll update the comment to make that clearer.

@@ -71,7 +44,7 @@ dependencies {
'org.apache.logging.log4j:log4j-slf4j-impl:2.8.+',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we move logging to dep management too? since there's no reason to use different versions across projects

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed; I'll do that as part of the bigger logging cleanup to move to slf4j everywhere.

This moves as much of our repeated subproject configuration as makes
sense to the root project, and versions more of the most common
dependencies using the dependencyManagement section.

This also consolidates all plugin versions in the root project using the
plugins {} block, and only applies them in subprojects that need them.
@wjbuys wjbuys merged commit 7ebb964 into blox:dev Nov 8, 2017
@wjbuys wjbuys deleted the chore-clean-up-build-logic branch November 8, 2017 20:12
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants