Skip to content
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

KAFKA-12415: Prepare for Gradle 7.0 and restrict transitive scope for non api dependencies #10203

Merged
merged 28 commits into from
Mar 4, 2021

Conversation

ijuma
Copy link
Contributor

@ijuma ijuma commented Feb 24, 2021

Gradle 7.0 is required for Java 16 compatibility and it removes a number of
deprecated APIs. Fix most issues preventing the upgrade to Gradle 7.0.
The remaining ones are more complicated and should be handled
in a separate PR. Details of the changes:

  • Release tarball no longer includes includes test, sources, javadoc and test sources jars (these
    are still published to the Maven Central repository).
  • Replace compile with api or implementation - note that implementation
    dependencies appear with runtime scope in the pom file so this is a (positive)
    change in behavior
  • Add missing dependencies that were uncovered by the usage of implementation
  • Replace testCompile with testImplementation
  • Replace runtime with runtimeOnly and testRuntime with testRuntimeOnly
  • Replace configurations.runtime with configurations.runtimeClasspath
  • Replace configurations.testRuntime with configurations.testRuntimeClasspath (except for
    the usage in the streams project as that causes a cyclic dependency error)
  • Use java-library plugin instead of java
  • Use maven-publish plugin instead of deprecated maven plugin - this changes the
    commands used to publish and to install locally, but task aliases for install and
    uploadArchives were added for backwards compatibility
  • Removed -x signArchives line from the readme since it was wrong (it was a
    no-op before and it fails now, however)
  • Replaces artifacts block with an approach that works with the maven-publish plugin
  • Don't publish jmh-benchmark module - the shadow jar is pretty large and not
    particularly useful (before this PR, we would publish the non shadow jars)
  • Replace version with archiveVersion, baseName with archiveBaseName and
    classifier with archiveClassifier
  • Update Gradle and plugins to the latest stable version (7.0 is not stable yet)
  • Use plugin DSL to configure plugins
  • Updated notable changes for 3.0

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@@ -1468,7 +1461,7 @@ project(':streams') {
include('log4j*jar')
include('*hamcrest*')
}
from (configurations.runtime) {
from (configurations.runtimeClasspath) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should also change configurations.testRuntime a few lines above to configurations.testRuntimeClasspath, but this causes a cyclic build error. Fixing this will be required before we move to Gradle 7.0.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a jira already?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ijuma ijuma marked this pull request as ready for review February 25, 2021 09:20
}
}

apply plugin: "com.diffplug.spotless"
plugins {
id 'com.diffplug.spotless' version '5.10.2'
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have to either include the version literal here or in a properties file. Methods cannot be invoked. Having a separate properties file and the dependencies file didn't seem particularly better than this way.

@ijuma
Copy link
Contributor Author

ijuma commented Feb 25, 2021

@chia7712 @omkreddy Any of you have cycles to review this? We reached the end of the road when it comes to delaying the handling of these Gradle deprecations. :)

Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

@ijuma thanks for this nice patch. Left some comments for this PR. please take a look.

build.gradle Outdated Show resolved Hide resolved
build.gradle Show resolved Hide resolved
README.md Show resolved Hide resolved
build.gradle Outdated Show resolved Hide resolved
Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

@ijuma Thanks for updating code. please take a look at following minor questions.

build.gradle Show resolved Hide resolved
build.gradle Outdated Show resolved Hide resolved
@ijuma
Copy link
Contributor Author

ijuma commented Feb 27, 2021

@mjsax @guozhangwang @vvcephei Can one of you review the build changes for the stream modules and check if they all make sense?

@ijuma
Copy link
Contributor Author

ijuma commented Mar 1, 2021

@chia7712 Are you ok after the latest changes?

Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

@ijuma thanks for updating patch. a couple of comments are left.

build.gradle Outdated Show resolved Hide resolved
release.py Show resolved Hide resolved
@@ -1468,7 +1461,7 @@ project(':streams') {
include('log4j*jar')
include('*hamcrest*')
}
from (configurations.runtime) {
from (configurations.runtimeClasspath) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a jira already?

* apache-github/trunk: (37 commits)
  KAFKA-10357: Extract setup of changelog from Streams partition assignor (apache#10163)
  KAFKA-10251: increase timeout for consuming records (apache#10228)
  KAFKA-12394; Return `TOPIC_AUTHORIZATION_FAILED` in delete topic response if no describe permission (apache#10223)
  MINOR: Disable transactional/idempotent system tests for Raft quorums (apache#10224)
  KAFKA-10766: Unit test cases for RocksDBRangeIterator (apache#9717)
  KAFKA-12289: Adding test cases for prefix scan in InMemoryKeyValueStore (apache#10052)
  KAFKA-12268: Implement task idling semantics via currentLag API (apache#10137)
  MINOR: Time and log producer state recovery phases (apache#10241)
  MINOR: correct the error message of validating uint32 (apache#10193)
  MINOR: Format the revoking active log output in `StreamsPartitionAssignor` (apache#10242)
  KAFKA-12323 Follow-up: Refactor the unit test a bit (apache#10205)
  MINOR: Remove stack trace of the lock exception in a debug log4j (apache#10231)
  MINOR: Word count should account for extra whitespaces between words (apache#10229)
  MINOR; Small refactor in `GroupMetadata` (apache#10236)
  KAFKA-10340: Proactively close producer when cancelling source tasks (apache#10016)
  KAFKA-12329; kafka-reassign-partitions command should give a better error message when a topic does not exist (apache#10141)
  KAFKA-12254: Ensure MM2 creates topics with source topic configs (apache#10217)
  MINOR: fix kafka-metadata-shell.sh (apache#10226)
  KAFKA-12374: Add missing config sasl.mechanism.controller.protocol (apache#10199)
  KAFKA-10101: Fix edge cases in Log.recoverLog and LogManager.loadLogs (apache#8812)
  ...
@rhauch
Copy link
Contributor

rhauch commented Mar 3, 2021

@ijuma, I ran ./gradlew clean install releaseTarGz -x signArchives (which is still in the README) and it failed with:

* What went wrong:
Task 'signArchives' not found in root project 'kafka'.

If that should not work, we should also update the README. But if it should work, we may need a bit more work for building an unsigned release archive.

FWIW, running ./gradew clean install releaseTarGz and ./gradlewAll publish both appear to work as expected.

@rhauch
Copy link
Contributor

rhauch commented Mar 3, 2021

A few more things regarding ./gradlewAll publishToMavenLocal or ./gradlewAll install:

  1. These do not appear to publish source, test or test source JARs to the local Maven repository, unlike ./gradlewAll install on the 2.8 branch.
  2. Is it intentional to no longer publish .asc files to the local Maven repository? I do see with this PR the install commands now publish .module files that contain the various hashes, but I don't know if that's expected.

I have Gradle 6.8.3 installed.

* apache-github/trunk:
  KAFKA-12400: Upgrade jetty to fix CVE-2020-27223
  MINOR: Fix null exception in coordinator log (apache#10250)
  y
  KAFKA-12375: don't reuse thread.id until a thread has fully shut down (apache#10215)
  KAFKA-12177: apply log start offset retention before time and size based retention (apache#10216)
  KAFKA-12369; Implement `ListTransactions` API (apache#10206)
@ijuma
Copy link
Contributor Author

ijuma commented Mar 3, 2021

Thanks for testing @rhauch!

@ijuma, I ran ./gradlew clean install releaseTarGz -x signArchives (which is still in the README) and it failed with:

The readme was wrong when it comes to this since signing was only triggered when uploadArchives was called. I updated the readme instead of making code changes.

These do not appear to publish source, test or test source JARs to the local Maven repository, unlike ./gradlewAll install on the 2.8 branch.

Good catch, I updated the build so that this works with the new plugin.

Is it intentional to no longer publish .asc files to the local Maven repository? I do see with this PR the install commands now publish .module files that contain the various hashes, but I don't know if that's expected.

It seems like the new plugin only includes those when publish is called instead of publishToMavenLocal. That seems fine, I don't see any reason why those files are useful when installing to the local repo.

build.gradle Outdated Show resolved Hide resolved
@chia7712
Copy link
Contributor

chia7712 commented Mar 3, 2021

The libs in distribution get changed.

before

截圖 2021-03-03 下午11 53 47

after

截圖 2021-03-03 下午11 53 55

Not sure whether it breaks something (for example, users want to run main class from test code?)

@@ -1833,27 +1848,30 @@ project(':jmh-benchmarks') {
apply plugin: 'com.github.johnrengelman.shadow'

shadowJar {
baseName = 'kafka-jmh-benchmarks-all'
classifier = null
Copy link
Contributor

Choose a reason for hiding this comment

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

Those changes rename the shadow jar from kafka-jmh-benchmarks-all.jar to kafka-jmh-benchmarks-all-3.0.0-SNAPSHOT-all.jar. That breaks jmh.sh as the script presumes the name of shadow jar is kafka-jmh-benchmarks-all.jar (https://github.com/apache/kafka/blob/trunk/jmh-benchmarks/jmh.sh#L40)

Copy link
Contributor Author

@ijuma ijuma Mar 3, 2021

Choose a reason for hiding this comment

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

Good point, fixed the script and readme.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could we remove duplicate "all" from name of shadow jar? kafka-jmh-benchmarks-all-3.0.0-SNAPSHOT-all.jar

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

@rhauch rhauch left a comment

Choose a reason for hiding this comment

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

The Connect portion looks correct. Thanks, @ijuma!

build.gradle Outdated
compile libs.jacksonDatabind
compile libs.jacksonJDK8Datatypes
compile libs.slf4jApi
implementation project(':connect:api')
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is the correct mapping.

By switching to implementation, any external project depending on the connect:json module will have to include an explicit dependency on connect:api. This appears to be have the same effect as what previous branches do with compile on earlier branches, but using implementation seems more correct since the Gradle docs suggest that compile (or compileOnly) are more applicable for shading, which is not our case here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does connect-json expose any connect-api types in its public API?

Copy link
Contributor

Choose a reason for hiding this comment

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

The public API is defined in connect:api, and connect:json and connect:transforms are implementations of interfaces defined in (and therefore cannot be used without) connect:api. Within AK, we provide the connect:json and connect:transforms always with the connect:api (and runtime) modules, and therefore using implementation (and compile in earlier branches) seems appropriate.

From a more abstract perspective, one might argue that the connect:json and connect:transforms could declare their use of connect:api as a transitive dependency (e.g., api rather than implementation). It's just that as a practical matter we don't need this, and arguably no other projects would either.

As such, I think it's safer to use implementation, as it's in line with what we were doing earlier.

Copy link
Contributor Author

@ijuma ijuma Mar 4, 2021

Choose a reason for hiding this comment

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

To clarify, compile is more like api than implementation. I switched the dependency of connect-api for connect-json and connect-transform to api for now. We can change this in a future PR, if we like, but it seems more consistent with the generally conservative approach we're taking in this PR.

Copy link
Contributor

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

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

LGTM

@ijuma ijuma changed the title MINOR: Prepare for Gradle 7.0 KAFKA-12415 Prepare for Gradle 7.0 and restrict transitive scope for non api dependencies Mar 4, 2021
@ijuma
Copy link
Contributor Author

ijuma commented Mar 4, 2021

@chia7712 I filed https://issues.apache.org/jira/browse/KAFKA-12418 to follow up on the jars that are no longer included in the release tarball. It seems OK to me, but I'll do a bit more due dilligence before the 3.0.0 release.

@ijuma
Copy link
Contributor Author

ijuma commented Mar 4, 2021

No test failures, but one of the jobs was killed in the last run:
https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-10203/19/testReport/

The previous runs confirm that it's a flaky issue unrelated to this PR (there are no test changes here).

@ijuma ijuma merged commit 7a3ebbe into apache:trunk Mar 4, 2021
@ijuma ijuma deleted the gradle-7.0-ready branch March 4, 2021 19:22
@ijuma ijuma changed the title KAFKA-12415 Prepare for Gradle 7.0 and restrict transitive scope for non api dependencies KAFKA-12415: Prepare for Gradle 7.0 and restrict transitive scope for non api dependencies Mar 4, 2021
@@ -69,10 +69,6 @@ Generate coverage for a single module, i.e.:
### Building a binary release gzipped tar ball ###
./gradlew clean releaseTarGz

The above command will fail if you haven't set up the signing key. To bypass signing the artifact, you can run:

./gradlew clean releaseTarGz -x signArchives
Copy link
Contributor

Choose a reason for hiding this comment

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

@ijuma the proper way to skip signing is now to run ./gradlew clean releaseTarGz -DskipSigning, is that right? Is there a reason we removed this instruction from the README instead of updating it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Signing is skipped by default. Are you seeing something different? There is a table that describes skipSigning:

Copy link
Contributor

@ableegoldman ableegoldman Mar 12, 2021

Choose a reason for hiding this comment

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

Yes, we're suddenly seeing our soak test (an application which deploys from trunk) fail with

./gradlew clean install releaseTarGz
> Configure project :
Building project 'core' with Scala version 2.13.5
Building project 'streams-scala' with Scala version 2.13.5
> Task :connect:signMavenJavaPublication FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':connect:signMavenJavaPublication'.
> Cannot perform signing task ':connect:signMavenJavaPublication' because it has no configured signatory

I personally haven't been able to reproduce this, but both @wcarlson5 and @lct45 have reported running into this issue

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note that your command has install while the README line I deleted did not (and was wrong). It is still weird that you're seeing this for snapshot builds. I'll work with you all offline to try and figure it out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We figured it out, the build was using a non snapshot version. Passing -PskipSigning=true fixed it. Submitted #10307 to make it easier to debug these issues in the future.

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.

4 participants