Make the Gradle build more idiomatic #1382
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Gradle itself deprecates HTTP repositories, so the check is redundant.
This commit introduces a convention plugin for libraries produced by this build. This is the first step in the build cleanup.
The 'target' directory is a relic of the Ant era. With Gradle the default output directory is named "build" and it's easier to follow the best practice.
This commit makes the `groovy-all` and `groovy-bom` components proper subprojects. This will allow us to publish them properly using standard Gradle mechanisms. The dependencies of the `groovy-bom` and `groovy-all` projects are defined dynamically thanks to the application of a plugin.
Using features, it's not necessary to tweak the generated POM files. See https://blog.gradle.org/optional-dependencies
This commit introduces more cleanup of the Gradle build, in particular how the jars are built. It simplifies how the jar manifests are created, while keeping the separation between the main groovy module and libraries. This commit makes also use of configuration avoidance whenever possible.
This commit reworks how publications are built. Before, the publishing mechanism used a bunch of internal APIs, as well as code to determine how to generate the POM files based on whether a module belonged to groovy-all or not, etc... Now, the fact of being part of Groovy all is part of the model. As such groovy-all is considered a platform, which with Gradle Module Metadata adds the advantage of providing native dependency version alignement. Because the Groovy modules published on external repositories are not the main "jars", but the "jarjar", we need to create custom components for publication, but this is all done using _public_ Gradle APIs, and much cleaner. The fact of repackaging dependencies determines whether the dependencies should be part of the module metadata or not.
This module should basically do what remains in `assemble.gradle`: it's about the end deliverables, which are the distribution zips, sources, ... It's modeled as a proper module so that we can publish it without hacking into internal APIs.
melix
changed the title
Make use of a distribution extension to configure things.
Instead of hardcoding projects which generate grooid jars, we now have an extension on the library to configure the grooid version.
Lots of the tests were actually reaching out to other project directories directly, making the relationships between projects hard to track, and possibly buggy. This commit reworks how tests are setup to use proper dependency management, and introduces the use of test fixtures in case a project needs a test fixture class from another project: instead of adding the test runtime classpath of the other project on its own test runtime classpath, we just add the required classes.
Again instead of blindly applying the plugin to all projects, it's now applied only where it makes sense and the aggregation is done on demand.
The backports modules are a bit special. If we want to keep them they would have to be reintroduced with a cleaner way of building.
This allows more task configuration avoidance, while making things cleaner!
melix
force-pushed
the
cc/gradle/update-publishing
branch
from
82bb958 to
bc95eb1
Compare
and offer the ability to use GPG command line
melix
force-pushed
the
cc/gradle/update-publishing
branch
from
45feb2b to
c018a78
Compare
The `dist` task should actually trigger the creation of all the "distribution" artifacts, instead of being the task which builds the SDK archive.
The setup was completely broken. There's a single test file being compiled, we should probably add way more to get significant numbers.
melix
force-pushed
the
cc/gradle/update-publishing
branch
from
9a0aaa3 to
bf9ed22
Compare
And move stress tests out of the main test suite
Now the jacoco plugin is applied conditionally, but more importantly it relies on standard Gradle configuration even for the aggregation.
Contributor
Author
|
PR looks fine from my POV. Let me know how we can make progress on merging this. |
Contributor
|
I will look at it soon. Might be a few days. Nice work! Thanks so much. |
Most of the build logic has moved to a precompiled script plugin which allows focusing on the configuration of the module instead.
Build services are configuration cache safe and have built-in resource limitation.
While we only read them, they are not declared so not compatible with the configuration cache.
and make the checkstyle report task cacheable.
This commit introduces dependency verification to the Groovy build. This is a security focused feature, in order to make sure no compromised library is introduced in the distribution.
wolfs
reviewed
Oct 3, 2020
buildSrc/src/main/groovy/org/apache/groovy/gradle/GroovyLibraryExtension.groovy
Show resolved
Hide resolved
and it's in a tmp directory anyway.
Contributor
|
Merged, Thanks!! Still a few glitches to unravel but with master continually updating, I think merging and some post amendments will be quickest path to get this in. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a PR which refactors the build in order to:
maven-publishplugin instead of the old oneInitially I only wanted to focus on the last point but I realized there's a LOT of hackery in the build which makes it complicated to migrate without doing the cleanup first.