Refactor Gradle build #1862
Refactor Gradle build #1862
Conversation
This was vestige from when desktop was managed as a separate repository.
- Move gradle-witness.jar to top level - Extract gradle-witness.gradle build file to top level Moving these files out of the gradle/ dir and the main build file to the top level of the repository calls them out and makes their presence and function more obvious. It also removes a lot of noise from the main build file.
This was a vestige from when desktop was managed as a separate repository.
This is used only in common/build.gradle and is obsolete here.
It is no longer necessary to publish Maven metadata about common, core and other submodules as they are no longer managed as separate libraries in separate repositories. The only way these modules should be getting referenced is from within applications in this repository such as desktop, statsnode, etc. Essentially, we're no longer publishing our libraries for public consumption.
Not all subprojects need it, but most do.
Previously, when assets was managed as a separate library and repository, its Javadoc was published via Jitpack and linked to from the documentation at https://bisq.network. This is no longer the case, and therefore building the Javadoc jar is no longer necessary.
And also relocate gradle-witness jar and config (back) to root-level gradle/witness dir.
To increase readability
This looks to have been a copy and paste error when originally setting up the seednode build.
This was needed at the root level for a while when first porting the build back to the monorepo, but is no longer necessary now.
|
hi Chris thx for the effort, could you have a quick look at the http-api gradle config to assess if it fits in the new structure? https://github.com/mrosseel/bisq/blob/http-api/http-api/build.gradle |
|
Looks like it’ll be straightforward to integrate. Happy to help when needed.
… On Nov 4, 2018, at 9:52 PM, mrosseel ***@***.***> wrote:
hi Chris thx for the effort, could you have a quick look at the http-api gradle config to assess if it fits in the new structure?
https://github.com/mrosseel/bisq/blob/http-api/http-api/build.gradle
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
great, once it's merged in master we'll have a go at it and call for help if necessary :) |
| } | ||
|
|
||
| dependencies { | ||
| testCompile 'junit:junit:4.12' |
There was a problem hiding this comment.
Since you have defined the junit version above, I assume this can be changed to the following?
testCompile "junit:junit:$junitVersion"
There was a problem hiding this comment.
Good catch. I extracted that variable when there were still multiple declarations of the same junit dependency across the projects. Now, however, there is just one declaration applied to all subprojects in the configure(subprojects) block, so I'll simply remove the variable as it's no longer needed. The practice here is to extract these variables only as needed to eliminate duplication. If there's just one declaration, the version can remain inline.
build.gradle
Outdated
| compile('com.googlecode.json-simple:json-simple:1.1.1') { | ||
| exclude(module: 'junit') | ||
| } | ||
| compile 'org.springframework:spring-core:4.3.6.RELEASE' |
There was a problem hiding this comment.
Since you have the spring version defined above, I assume this can be changed to the following?
compile "org.springframework:spring-core:$springVersion"
There was a problem hiding this comment.
Yes, an oversight on my part, thanks. Fixed in 978fd2d.
| apply plugin: 'witness' | ||
| apply from: '../gradle/witness/gradle-witness.gradle' | ||
|
|
||
| version = '0.8.0-SNAPSHOT' |
There was a problem hiding this comment.
A comment that is out of scope for this PR. But perhaps this should be taken out of the gradle file and put into a resource file, similar to how it is done for pricenode?
version = file("src/main/resources/version.txt").text
There was a problem hiding this comment.
Yeah, I cleaned up a number of unnecessary, unused, or just wrong instances of version metadata elsewhere in this PR, but in this case, the assignment of the $project.version variable affects the name of the resulting jar and shadow jar, so it's not quite as simple as extracting it to a resource file. There is also a lot of duplication of the current version throughout the codebase and supporting shell scripts that are used during releases. As you mention, it's a topic for another, more comprehensive PR that really cleans this stuff up.
Per review comments at bisq-network#1862 (comment).
Per review feedback at bisq-network#1862 (comment).
There was a problem hiding this comment.
ACK - works for me. Thanks for cleaning up the build scripts @cbeams and @devinbileck!
This PR supersedes @devinbileck's similar work at #1808. It makes a number of similar changes, does a few things differently, and then goes a good deal further toward simplifying the build arrangement. This is work that I've been meaning to do since reconsolidating into a single repository, but am just now getting to (thanks Devin for spurring that on).
There is now just a single
build.gradlefile in the root directory that usesconfigureblocks to configure each project in turn. It's important to understand that these blocks are additive. That is, it's possible to configure several projects at once in a singleconfigureblock, and then further configure each individual project in a dedicatedconfigureblock. You can see this being done in the way that all subprojects with amainmethod are configured with theapplicationplugin in a singleconfigureblock, and then how each of those projects are further configured individually with their specific dependencies, etc, in subsequent blocks.The bottom line is that we now have one-stop shopping for all our build needs, while still keeping concerns separated. Much cruft and duplication has been removed, and we're not doing anything really fancy with the build anywhere. It should be possible, with a minimum of ramp-up time for contributors not too familiar with Gradle to understand what's going on and to be able to make what changes they need. If you are one of those contributors, and find this new arrangement otherwise, please let me know.