KTOR-7743 Make projects isolated #4740
Conversation
|
Important Review skippedMore than 25% of the files skipped due to max files limit. The review is being skipped to prevent a low-quality review. 44 files out of 158 files are above the max files limit of 100. Please upgrade to Pro plan to get higher limits. You can disable this status message by setting the WalkthroughThe changes update the project’s Gradle build scripts across multiple modules—including build-logic, client, server, and shared components. New dependencies and plugins (e.g., Kotlin serialization, ktorbuild.project.library/client-plugin/server-plugin) are introduced, along with a refactoring of the Kotlin DSL syntax for source set and dependency declarations. Property access is now improved via Gradle’s providers API, and obsolete configurations, files, and module includes have been removed. Copyright notices and naming conventions have been updated consistently throughout, resulting in a more streamlined, standardized build configuration. Changes
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
osipxd
changed the title
osipxd
force-pushed
the
osipxd/precompiled-script-plugins
branch
from
deef566 to
63abd23
Compare
| @@ -1339,8 +1331,6 @@ ktor-server-websockets-watchosarm64 | |||
| ktor-server-websockets-watchosdevicearm64 | |||
| ktor-server-websockets-watchossimulatorarm64 | |||
| ktor-server-websockets-watchosx64 | |||
| ktor-shared | |||
| ktor-shared-jvm | |||
There was a problem hiding this comment.
These artifacts were empty, but I'm a bit worried that it is a potentially breaking change and it doesn't fit a patch release.
There was a problem hiding this comment.
Seems that it would only break project that are explicitly importing it, which wouldn't make any sense...
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (22)
ktor-server/ktor-server-plugins/ktor-server-forwarded-header/build.gradle.kts (1)
5-6: Empty Description Notice
Thedescriptionproperty is currently an empty string. Consider adding a brief module description to improve clarity and documentation.ktor-server/ktor-server-plugins/ktor-server-cors/build.gradle.kts (1)
5-6: Missing Module Description
Thedescriptionproperty is currently left empty. Adding a short description could help future maintainers understand the module’s purpose.ktor-server/ktor-server-plugins/ktor-server-http-redirect/build.gradle.kts (1)
5-6: Module Description Enhancement Suggestion
Thedescriptionfield is empty. Providing a concise summary for the module could be beneficial for documentation purposes.ktor-server/ktor-server-plugins/ktor-server-double-receive/build.gradle.kts (1)
5-6: Consider Adding Module Description
Thedescriptionproperty is empty. For better clarity and maintainability, consider providing a brief description of the module.ktor-server/ktor-server-plugins/ktor-server-compression/build.gradle.kts (1)
5-6: Empty Description WarningThe
descriptionfield is currently an empty string. Providing a clear, meaningful description (e.g., "Compression plugin for Ktor Server") would improve maintainability and clarity.ktor-server/ktor-server-plugins/ktor-server-method-override/build.gradle.kts (1)
5-6: Proposal for a Meaningful DescriptionThe description is currently an empty string. It is recommended to provide a concise description (e.g., "Method Override plugin for Ktor Server") to improve module clarity.
ktor-server/ktor-server-plugins/ktor-server-i18n/build.gradle.kts (1)
5-6: Consider Improving Description GrammarThe current description reads "I18n support to Ktor". For clarity and better readability, consider changing it to "I18n support for Ktor".
ktor-client/build.gradle.kts (1)
10-13: Simplified Dependency Declaration
Restructuring thecommonMain.dependenciesblock to directly declareapi(project(":ktor-client:ktor-client-core"))improves readability and reduces nesting. Verify that there are no unintended side effects from flattening this block.ktor-server/ktor-server-plugins/ktor-server-swagger/build.gradle.kts (1)
9-15: Streamlined Dependency Declaration forjvmMain
By modifying the source set to use a flattened dependency declaration forjvmMain(lines 11-13), the build script becomes less nested and more maintainable. Confirm that the dependency onktor-server-html-builderis correct and that no additional configuration is needed.build-logic/src/main/kotlin/ktorbuild.project.library.gradle.kts (1)
5-6: Wildcard Import from ktorbuild Module.
The new import statementimport ktorbuild.*grants access to required utilities. Consider refining this to a more specific import in the future to minimize namespace pollution if only a subset of the package is needed.ktor-client/ktor-client-android/build.gradle.kts (1)
27-29: Verification of JVM Test Task Settings
The configuration of thejvmTesttask with a JVM argument (-Dhttp.maxConnections=32) is maintained. It might be worthwhile to verify that this setting remains optimal given the isolated project environment.ktor-server/ktor-server-plugins/ktor-server-html-builder/build.gradle.kts (1)
5-7: Plugin Declaration SimplificationThe addition of the
ktorbuild.project.server-pluginin this file helps standardize the server configuration across modules. Please ensure that documentation and related module setup align with this plugin’s behavior.ktor-client/ktor-client-plugins/ktor-client-call-id/build.gradle.kts (1)
23-25: Test Tasks ConfigurationDisabling the
jsBrowserTestandwasmJsBrowserTesttasks acknowledges the current dependency on the server environment for tests. Consider adding a more detailed comment or documentation note to explain why these tests are conditionally disabled, to assist future maintainers.ktor-client/ktor-client-plugins/ktor-client-websockets/build.gradle.kts (1)
9-15: Refactored Kotlin DSL Configuration
The updatedkotlinblock now explicitly defines thesourceSetsand its dependencies. This streamlined syntax reduces vertical nesting and improves readability. Please ensure that the dependency on the logging plugin (defined in line 12) resolves correctly in the new structure.ktor-shared/ktor-resources/build.gradle.kts (1)
12-20: Kotlin SourceSets Restructuring
The Kotlin DSL now nests thesourceSetsblock and declares dependencies directly
undercommonMain.dependencies. This flattening improves readability and maintains
consistency with similar changes in other modules.ktor-server/ktor-server-jetty/ktor-server-jetty-test-http2/build.gradle.kts (1)
11-21: Kotlin DSL SourceSets Update for jvmTest
The restructuring of thekotlinblock—with the nestedsourceSetsforjvmTest
dependencies—provides a cleaner, more maintainable declaration of module dependencies.
This streamlined structure is in line with the PR objectives.build-logic/src/main/kotlin/ktorbuild.base.gradle.kts (1)
5-6: Wildcard Import Usage
Switching to a wildcard import (import ktorbuild.*) simplifies the inclusion of all
public members from the package. Confirm that this change adheres to the project’s
import style guidelines, as wildcard imports can sometimes lead to namespace pollution.ktor-client/ktor-client-darwin/build.gradle.kts (1)
5-8: Plugin Configuration ReviewThe addition of
id("ktorbuild.project.library")is consistent with the refactoring objectives. However, please verify that includingid("test-server")in a client module is intentional—as its naming suggests a server-related function—and document its purpose if necessary.ktor-server/ktor-server-servlet/build.gradle.kts (1)
7-10: Plugin Selection VerificationThe file applies the
ktorbuild.project.libraryplugin. Please confirm that this choice is deliberate for thektor-server-servletmodule—considering that other server modules sometimes use theserver-plugin—so that the distinction between library and server modules remains clear.ktor-client/ktor-client-mock/build.gradle.kts (1)
10-29: Updated Source Set Dependencies Syntax.
The new structure under thekotlin { sourceSets { ... } }block removes unnecessary nesting by directly declaring dependencies for each source set. This improves clarity and maintainability and is consistent with the unified configuration approach outlined in the PR objectives.ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-json/build.gradle.kts (1)
12-33: Streamlined Source Set Declarations with Minor Inconsistency.
While the updated syntax for declaring dependencies undercommonMainandcommonTestenhances readability, thejvmTestblock still uses a nesteddependencies { ... }construct (with an accompanying suppression annotation). If the suppression is necessary, it’s acceptable; otherwise, consider aligning it with the direct declaration style for consistency.build-logic/src/main/kotlin/ktorbuild/ProjectTagsService.kt (1)
115-127: Clear enumeration of project tagsThe
ProjectTagenum provides a good categorization with informative comments about hierarchical relationships between tags.Consider adding validation to ensure that projects with
Librarytag also havePublishedtag (since the comment statesLibraryimpliesPublished). Similarly forJvmimplyingLibrary. This would help maintain tag consistency:fun Project.addProjectTag(tag: ProjectTag) { + // Ensure implied tags are also added + when (tag) { + ProjectTag.Library -> addProjectTag(ProjectTag.Published) + ProjectTag.Jvm -> { + addProjectTag(ProjectTag.Library) + // Published is added transitively by Library + } + else -> { /* no implied tags */ } + } projectTagsService.addTag(this, tag) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (151)
build-logic/build.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.base.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.doctor.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.kmp.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.project.client-plugin.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.project.library.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.project.server-plugin.gradle.kts(1 hunks)build-logic/src/main/kotlin/ktorbuild.publish.gradle.kts(2 hunks)build-logic/src/main/kotlin/ktorbuild.publish.verifier.gradle.kts(2 hunks)build-logic/src/main/kotlin/ktorbuild/ProjectTagsService.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/dsl/Collections.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/dsl/KotlinSourceSets.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/Train.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/Version.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/gradle/NamedDomainObjectCollection.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/gradle/Property.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/publish/PublishTasks.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/internal/publish/ValidatePublishedArtifactsTask.kt(3 hunks)build-logic/src/main/kotlin/ktorbuild/targets/JsConfig.kt(1 hunks)build-logic/src/main/kotlin/ktorbuild/targets/JvmConfig.kt(3 hunks)build-logic/src/main/kotlin/ktorbuild/targets/KtorTargets.kt(2 hunks)build.gradle.kts(1 hunks)buildSrc/build.gradle.kts(0 hunks)buildSrc/settings.gradle.kts(0 hunks)buildSrc/src/main/kotlin/KotlinExtensions.kt(0 hunks)buildSrc/src/main/kotlin/NamedDomainObjectCollection.kt(0 hunks)gradle/artifacts.txt(0 hunks)ktor-bom/build.gradle.kts(2 hunks)ktor-client/build.gradle.kts(1 hunks)ktor-client/ktor-client-android/build.gradle.kts(1 hunks)ktor-client/ktor-client-apache/build.gradle.kts(1 hunks)ktor-client/ktor-client-apache5/build.gradle.kts(1 hunks)ktor-client/ktor-client-cio/build.gradle.kts(1 hunks)ktor-client/ktor-client-core/build.gradle.kts(1 hunks)ktor-client/ktor-client-curl/build.gradle.kts(2 hunks)ktor-client/ktor-client-darwin-legacy/build.gradle.kts(1 hunks)ktor-client/ktor-client-darwin/build.gradle.kts(1 hunks)ktor-client/ktor-client-ios/build.gradle.kts(1 hunks)ktor-client/ktor-client-java/build.gradle.kts(2 hunks)ktor-client/ktor-client-jetty-jakarta/build.gradle.kts(1 hunks)ktor-client/ktor-client-jetty/build.gradle.kts(1 hunks)ktor-client/ktor-client-js/build.gradle.kts(1 hunks)ktor-client/ktor-client-mock/build.gradle.kts(1 hunks)ktor-client/ktor-client-okhttp/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/build.gradle.kts(0 hunks)ktor-client/ktor-client-plugins/ktor-client-auth/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-bom-remover/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-call-id/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-content-negotiation/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-content-negotiation/ktor-client-content-negotiation-tests/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-encoding/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-json/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-gson/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-jackson/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-serialization/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-logging/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-resources/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-tracing/build.gradle.kts(1 hunks)ktor-client/ktor-client-plugins/ktor-client-websockets/build.gradle.kts(1 hunks)ktor-client/ktor-client-test-base/build.gradle.kts(1 hunks)ktor-client/ktor-client-tests/build.gradle.kts(4 hunks)ktor-client/ktor-client-winhttp/build.gradle.kts(2 hunks)ktor-dokka/build.gradle.kts(2 hunks)ktor-http/build.gradle.kts(1 hunks)ktor-http/ktor-http-cio/build.gradle.kts(1 hunks)ktor-io/build.gradle.kts(1 hunks)ktor-java-modules-test/build.gradle.kts(3 hunks)ktor-network/build.gradle.kts(1 hunks)ktor-network/ktor-network-tls/build.gradle.kts(1 hunks)ktor-network/ktor-network-tls/ktor-network-tls-certificates/build.gradle.kts(1 hunks)ktor-server/build.gradle.kts(1 hunks)ktor-server/ktor-server-cio/build.gradle.kts(1 hunks)ktor-server/ktor-server-config-yaml/build.gradle.kts(1 hunks)ktor-server/ktor-server-core/build.gradle.kts(1 hunks)ktor-server/ktor-server-host-common/build.gradle.kts(1 hunks)ktor-server/ktor-server-jetty-jakarta/build.gradle.kts(1 hunks)ktor-server/ktor-server-jetty-jakarta/ktor-server-jetty-test-http2-jakarta/build.gradle.kts(1 hunks)ktor-server/ktor-server-jetty/build.gradle.kts(1 hunks)ktor-server/ktor-server-jetty/ktor-server-jetty-test-http2/build.gradle.kts(1 hunks)ktor-server/ktor-server-netty/build.gradle.kts(3 hunks)ktor-server/ktor-server-plugins/build.gradle.kts(0 hunks)ktor-server/ktor-server-plugins/ktor-server-auth-jwt/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-auth-ldap/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-auth/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-auto-head-response/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-body-limit/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-caching-headers/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-call-id/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-call-logging/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-compression/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-conditional-headers/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-content-negotiation/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-cors/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-csrf/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-data-conversion/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-default-headers/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-double-receive/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-forwarded-header/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-freemarker/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-hsts/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-html-builder/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-http-redirect/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-i18n/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-jte/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-method-override/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-metrics-micrometer/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-metrics/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-mustache/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-openapi/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-partial-content/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-pebble/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-rate-limit/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-request-validation/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-resources/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-sessions/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-sse/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-status-pages/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-swagger/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-thymeleaf/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-velocity/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-webjars/build.gradle.kts(1 hunks)ktor-server/ktor-server-plugins/ktor-server-websockets/build.gradle.kts(1 hunks)ktor-server/ktor-server-servlet-jakarta/build.gradle.kts(1 hunks)ktor-server/ktor-server-servlet/build.gradle.kts(1 hunks)ktor-server/ktor-server-test-base/build.gradle.kts(1 hunks)ktor-server/ktor-server-test-host/build.gradle.kts(2 hunks)ktor-server/ktor-server-test-suites/build.gradle.kts(1 hunks)ktor-server/ktor-server-tests/build.gradle.kts(1 hunks)ktor-server/ktor-server-tomcat-jakarta/build.gradle.kts(1 hunks)ktor-server/ktor-server-tomcat/build.gradle.kts(1 hunks)ktor-shared/build.gradle.kts(0 hunks)ktor-shared/ktor-call-id/build.gradle.kts(1 hunks)ktor-shared/ktor-events/build.gradle.kts(1 hunks)ktor-shared/ktor-resources/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-gson/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-jackson/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-cbor/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-json/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-protobuf/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-tests/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-xml/build.gradle.kts(1 hunks)ktor-shared/ktor-serialization/ktor-serialization-tests/build.gradle.kts(1 hunks)ktor-shared/ktor-sse/build.gradle.kts(1 hunks)ktor-shared/ktor-test-base/build.gradle.kts(1 hunks)ktor-shared/ktor-websocket-serialization/build.gradle.kts(1 hunks)ktor-shared/ktor-websockets/build.gradle.kts(1 hunks)ktor-test-dispatcher/build.gradle.kts(1 hunks)ktor-utils/build.gradle.kts(2 hunks)settings.gradle.kts(0 hunks)
💤 Files with no reviewable changes (9)
- buildSrc/settings.gradle.kts
- ktor-shared/build.gradle.kts
- ktor-server/ktor-server-plugins/build.gradle.kts
- settings.gradle.kts
- buildSrc/src/main/kotlin/NamedDomainObjectCollection.kt
- buildSrc/build.gradle.kts
- ktor-client/ktor-client-plugins/build.gradle.kts
- gradle/artifacts.txt
- buildSrc/src/main/kotlin/KotlinExtensions.kt
🔇 Additional comments (366)
build-logic/src/main/kotlin/ktorbuild/internal/gradle/NamedDomainObjectCollection.kt (1)
5-5: Updated Package Declaration
The package declaration has been updated toktorbuild.internal.gradle, which clearly reflects its new internal gradle grouping. This change improves the modular organization of the build-logic code.ktor-shared/ktor-websockets/build.gradle.kts (2)
5-7: Standardized Plugin Application
The new plugins block applyingktorbuild.project.libraryis correctly configured. This adheres to the new isolated project approach and simplifies dependency management.
9-16: Clear Source Set Configuration
The Kotlin DSL block underkotlin { sourceSets { ... } }cleanly declares the dependencies forcommonMain(with API exposures to:ktor-utilsand:ktor-http). This concise and consistent configuration improves readability and maintainability.ktor-shared/ktor-call-id/build.gradle.kts (1)
2-7: Updated Build Script for Consistency
The copyright notice has been updated and the introduction of the
ktorbuild.project.libraryplugin aligns this module with the new project standards.
Make sure the description accurately reflects the module’s purpose.ktor-test-dispatcher/build.gradle.kts (2)
5-7: Proper Plugin Integration
The plugins block now includesktorbuild.project.library, which standardizes the build configuration across modules. This promotes consistency and isolation in the project builds.
10-16: Streamlined Source Sets Declaration
The restructuring of the sourceSets block, where dependencies forcommonMainandposixMainare now declared directly, enhances clarity. The use of direct dependency configuration avoids unnecessary nesting and improves overall readability.ktor-shared/ktor-serialization/ktor-serialization-jackson/build.gradle.kts (3)
2-3: Updated Copyright Notice
The copyright year has been updated to "2014-2025", ensuring the legal headers are current.
7-7: Consistent Plugin Declaration
The addition of thektorbuild.project.libraryplugin in the plugins block brings this module in line with the new isolated project structure.
11-27: Refined Dependency Configuration in Source Sets
The sourceSets configuration now directly declares dependencies for bothjvmMainandjvmTestusing a flattened syntax. This not only simplifies the build script but also enhances maintainability by reducing vertical nesting. All dependency declarations remain intact and correctly reference the necessary projects and libraries.build-logic/src/main/kotlin/ktorbuild/targets/JsConfig.kt (1)
8-8: Updated import formaybeNamedfunction.
The import has been switched from the old package toktorbuild.internal.gradle.maybeNamedin order to align with the refactored module structure. Verify that all usages ofmaybeNamednow resolve correctly.ktor-network/ktor-network-tls/ktor-network-tls-certificates/build.gradle.kts (3)
2-3: Update copyright header.
The copyright header has been updated to reflect the new range (2014-2025).
5-7: Addktorbuild.project.libraryplugin.
Introducing the new library plugin standardizes the build configuration across modules. Ensure that downstream configurations adapt to this change if needed.
9-17: Streamline dependency declarations in sourceSets.
The dependency blocks forjvmMainandjvmTesthave been simplified using direct assignment of dependencies. This enhances readability without altering functionality.ktor-client/ktor-client-darwin-legacy/build.gradle.kts (3)
2-3: Update copyright header.
The header update to 2025 is consistent with other modules and reflects current copyright information.
5-8: Addktorbuild.project.libraryplugin.
Adding this plugin helps streamline the library project configurations. Ensure any custom logic provided by the previous configuration is properly migrated if applicable.
12-19: Refactor dependency declarations for Darwin source sets.
The syntax for declaring dependencies indarwinMainanddarwinTesthas been refactored to directly assign dependencies. This promotes clarity and consistency across the build scripts.ktor-network/build.gradle.kts (4)
9-11: Addktorbuild.project.libraryplugin.
The new plugin is now applied to the project, aligning it with the overall strategy to modularize and isolate configurations across the repository.
20-22: Simplify dependency declaration forcommonMain.
Directly assigning dependencies (i.e.api(project(":ktor-utils"))) reduces nested block complexity while maintaining the intended behavior.
24-26: Simplify dependency declaration forcommonTest.
Switching to a direct assignment style enhances readability and consistency across source sets.
28-30: Simplify dependency declaration forjvmTest.
The refactored syntax here minimizes nesting and aligns with best practices as observed in other modules.ktor-io/build.gradle.kts (3)
8-10: Addktorbuild.project.libraryplugin.
The inclusion of the new library project plugin furthers the goal of standardized and isolated project configurations.
16-18: Refactor dependency declaration forcommonMain.
Using a direct dependency assignment (api(libs.kotlinx.io.core)) streamlines the configuration and increases maintainability.
19-21: Refactor dependency declaration forcommonTest.
Reducing nesting by directly assigningapi(project(":ktor-test-dispatcher"))promotes better clarity in the DSL configuration.ktor-network/ktor-network-tls/build.gradle.kts (3)
2-2: Updated Copyright Header
The copyright notice has been updated to include the current year range (2014-2025). This update is consistent with the overall project maintenance.
5-7: Adoption of Library Plugin
The new plugins block applyingktorbuild.project.libraryis correctly introduced. This refactoring aligns with the objective of isolating project configurations.
9-23: Kotlin DSL Configuration Enhancements
The restructured Kotlin DSL block—defining source sets and dependencies (for bothcommonMainandjvmTest)—is clean and consistent with the updated Gradle conventions. Please verify that all dependent projects and modules are adjusted accordingly.ktor-server/ktor-server-plugins/ktor-server-forwarded-header/build.gradle.kts (2)
2-2: Updated Copyright Information
The file’s header has been updated to reflect the current range (2014-2025).
7-9: Server Plugin Integration
The newly introduced plugins block applyingktorbuild.project.server-pluginis correctly implemented. Ensure that its usage remains consistent across all server modules for uniformity.ktor-server/ktor-server-plugins/ktor-server-cors/build.gradle.kts (2)
2-2: Updated Copyright Notice
The copyright header is updated to “2014-2025”, which keeps the file current and consistent with project standards.
7-9: Server Plugin Declaration
The addition of thektorbuild.project.server-pluginin the plugins block is well executed. This change supports the modular plugin management strategy adopted across the project.ktor-server/ktor-server-plugins/ktor-server-http-redirect/build.gradle.kts (2)
2-2: Updated Copyright Information
The header now correctly reflects “2014-2025”, keeping the file up-to-date with the current standards.
7-9: Server Plugin Setup Verification
The new plugins block withktorbuild.project.server-pluginis correctly added. This update is consistent with similar changes made in other server plugin modules.ktor-server/ktor-server-plugins/ktor-server-double-receive/build.gradle.kts (2)
2-2: Updated Copyright Notice
The copyright header now reflects the current range (2014-2025), which aligns with the project’s standards.
7-9: Server Plugin Declaration Confirmation
The inclusion ofktorbuild.project.server-pluginin the plugins block is properly implemented. This change supports the new isolated and modular project structure.ktor-server/ktor-server-plugins/ktor-server-body-limit/build.gradle.kts (2)
1-3: Updated Copyright NoticeThe copyright header has been updated to "2014-2025", which correctly reflects the current licensing period.
7-9: New Server Plugin DeclarationThe addition of the plugin declaration
id("ktorbuild.project.server-plugin")aligns with the objective to isolate projects and streamline build configuration. Please ensure that this plugin is used consistently across all server modules.
ktor-server/ktor-server-plugins/ktor-server-compression/build.gradle.kts (2)
1-3: Updated Copyright NoticeThe updated copyright header now correctly uses "2014-2025".
7-9: Server Plugin InclusionThe inclusion of
ktorbuild.project.server-pluginis consistent with the refactoring goals for project isolation. Ensure that this approach is uniformly applied across related modules.ktor-client/ktor-client-plugins/ktor-client-auth/build.gradle.kts (2)
1-3: Updated Copyright NoticeThe copyright header has been updated to "2014-2025", which is correct.
7-10: Client Plugin DeclarationThe new plugin declaration
id("ktorbuild.project.client-plugin")fits well with the project’s move towards isolated builds and simplified dependency management. Additionally, please verify that existing plugins (like
test-server) are not unintentionally affected by this change.ktor-server/ktor-server-plugins/ktor-server-method-override/build.gradle.kts (2)
1-3: Updated Copyright NoticeThe header now correctly reflects the period "2014-2025".
7-9: Server Plugin InclusionThe added plugin declaration
id("ktorbuild.project.server-plugin")is appropriate for aligning this module with the new isolated project setup. Confirm that this change is compatible with existing build scripts.
ktor-server/ktor-server-plugins/ktor-server-i18n/build.gradle.kts (2)
1-3: Updated Header InformationThe file header has been updated with the correct copyright details ("2014-2025") and license information.
7-9: Server Plugin DeclarationThe inclusion of the plugin
id("ktorbuild.project.server-plugin")correctly integrates this module into the new isolated project structure. This is in line with the overall refactoring objectives.
ktor-server/ktor-server-plugins/ktor-server-hsts/build.gradle.kts (2)
2-2: Update Copyright Year
The copyright notice has been updated from 2014-2020 to 2014-2025, ensuring the file’s license header reflects the current year.
7-9: Add Server Plugin Declaration
The new declaration of thektorbuild.project.server-pluginwithin the plugins block aligns this module with the refactoring for isolated projects and simplifies the build configuration.ktor-server/ktor-server-plugins/ktor-server-auto-head-response/build.gradle.kts (2)
2-2: Update Copyright Year
Updating the copyright header to "2014-2025" keeps the license information current and consistent with the rest of the project.
7-9: Add Server Plugin Declaration
Introducing thektorbuild.project.server-pluginhere modernizes the build script by leveraging the new isolated project approach and lazy evaluation.ktor-server/ktor-server-plugins/ktor-server-caching-headers/build.gradle.kts (2)
2-2: Update Copyright Year
The header now correctly reflects "2014-2025", ensuring legal and documentation consistency across the project files.
7-9: Add Server Plugin Declaration
Adding thektorbuild.project.server-plugindeclaration standardizes this module’s build configuration, contributing to the overall build infrastructure improvements.ktor-client/ktor-client-plugins/ktor-client-bom-remover/build.gradle.kts (2)
2-2: Update Copyright Year
The license header is updated to "2014-2025", keeping the legal information up-to-date and consistent with the other modules.
7-9: Add Client Plugin Declaration
The inclusion ofktorbuild.project.client-pluginin the plugins block simplifies the dependency declaration and aligns this client module with the new isolated plugin strategy.ktor-server/ktor-server-plugins/ktor-server-conditional-headers/build.gradle.kts (2)
2-2: Update Copyright Year
The file header now uses the updated range "2014-2025" which is consistent across all project files.
7-9: Add Server Plugin Declaration
Adding thektorbuild.project.server-plugindeclaration ensures that this module benefits from the refactored build process aimed at isolated and lazily evaluated configurations.build-logic/build.gradle.kts (1)
9-13: New Kotlin Serialization Dependency Added
The addition ofimplementation(libs.kotlin.serialization)(line 11) correctly introduces the Kotlin serialization library as a dependency. Ensure that the version defined in your version catalog (libs.kotlin.serialization) is consistent with the rest of the project’s dependencies.ktor-client/build.gradle.kts (2)
1-3: Updated Copyright Notice
The copyright header has been updated to "2014-2025." This ensures that the file’s legal notice is current. Verify that similar updates were applied consistently across the project.
5-7: Addition of Project Library Plugin
The newplugins { id("ktorbuild.project.library") }block (lines 5-7) standardizes the configuration across modules. Confirm that thektorbuild.project.libraryplugin is available and correctly configured in your build logic.ktor-server/ktor-server-plugins/ktor-server-rate-limit/build.gradle.kts (2)
1-3: Updated Copyright and Licensing
The copyright header now reflects "2014-2025." This update is in line with keeping the legal notices current across the repository.
5-8: New Server Plugin Declaration
The inclusion ofid("ktorbuild.project.server-plugin")within the plugins block (lines 6-8) sets up this module to use the standardized server plugin configuration. This change enhances consistency in how server plugins are managed.ktor-shared/ktor-events/build.gradle.kts (3)
1-4: Updated Copyright Notice
As with other files, updating to "2014-2025" ensures the file’s licensing is current.
5-7: Application of the Library Plugin
The newly addedplugins { id("ktorbuild.project.library") }block is correctly placed. This aligns with the broader project effort to standardize build configurations across shared modules.
9-15: Flattened Dependency Configuration forcommonMain
Flattening the dependency declaration (lines 11-12) to directly includeapi(project(":ktor-utils"))improves clarity and reduces unnecessary nesting. This modernized approach should help maintain consistency across modules.ktor-server/ktor-server-plugins/ktor-server-swagger/build.gradle.kts (2)
1-3: Updated Copyright Notice
The file’s copyright header has been updated to "2014-2025," ensuring legal consistency across modules.
5-7: New Server Plugin Declaration
The addition of thepluginsblock withid("ktorbuild.project.server-plugin")(lines 5-7) correctly integrates the standardized server plugin configuration. Ensure that this change is mirrored across similar server plugin modules within the project.ktor-server/ktor-server-plugins/ktor-server-data-conversion/build.gradle.kts (2)
1-3: Updated Copyright Notice.
The copyright notice has been extended to 2025, which aligns with current legal guidelines and project messaging.
7-9: Server Plugin Declaration Added.
The added plugin declarationid("ktorbuild.project.server-plugin")standardizes the configuration across server modules. This supports the new isolated project model.build-logic/src/main/kotlin/ktorbuild.project.library.gradle.kts (1)
13-14: Tagging as a Library Project.
The addition ofaddProjectTag(ProjectTag.Library)effectively categorizes this module as a library, which will help in project aggregation and dependency management.ktor-client/ktor-client-ios/build.gradle.kts (3)
1-4: Updated File Header.
The header now reflects the correct copyright range (2014-2025), ensuring that legal information remains current.
5-7: Library Plugin Inclusion.
Addingid("ktorbuild.project.library")aligns this module with the new standardized configuration for library projects, promoting consistency across client modules.
11-12: Streamlined Dependency Declaration for darwinMain.
Directly configuringdarwinMain.dependenciessimplifies the dependency declaration and removes unnecessary nesting, contributing to a cleaner Gradle script.ktor-server/ktor-server-plugins/ktor-server-csrf/build.gradle.kts (2)
1-3: Updated Copyright Notice.
The copyright notice update to 2025 reflects current standards and ensures consistency across server modules.
7-9: Server Plugin Declaration Confirmed.
The inclusion ofid("ktorbuild.project.server-plugin")is consistent with the refactoring objectives to isolate project configurations and modernize plugin usage across the Ktor server ecosystem.build-logic/src/main/kotlin/ktorbuild.kmp.gradle.kts (1)
7-9: Refined Import for Internal API.
The import change fromktorbuild.maybeNamedtoktorbuild.internal.gradle.maybeNamedclarifies that the function is now part of the internal Gradle utilities. Make sure that all references tomaybeNamedelsewhere are updated accordingly.ktor-server/ktor-server-host-common/build.gradle.kts (3)
1-4: License Header Update:
The updated license header reflects the new year range (2014-2025) and is correctly applied.
7-9: Plugin Declaration – Library Module:
The addition of thektorbuild.project.libraryplugin standardizes the configuration for library projects. This change aids in decoupling cross-project configuration and aligns with the PR's objective of project isolation.
13-14: Streamlined Dependency Declaration:
Refactoring thecommonMain.dependenciesblock to directly declare the dependency (usingapi(project(":ktor-server:ktor-server-core"))) simplifies the build script by removing an unnecessary nesting level.ktor-server/ktor-server-plugins/ktor-server-velocity/build.gradle.kts (3)
2-3: License Header Update:
The header now reflects the updated copyright (2014-2025), ensuring consistency with other files.
5-7: Plugin Addition – Server Plugin:
Introducing thektorbuild.project.server-pluginhere aligns with the broader refactoring effort for Ktor server plugins. This change supports isolated project evaluation and lazy configuration, as outlined by the PR objectives.
11-19: Direct Dependency Blocks for JVM Source Sets:
The restructuring of thejvmMain.dependenciesandjvmTest.dependenciesblocks to directly declare the required dependencies (including libraries such aslibs.velocityand related projects) improves clarity and maintainability.build-logic/src/main/kotlin/ktorbuild.project.server-plugin.gradle.kts (3)
1-4: License Header Update:
The updated copyright header is correctly applied and
reflects the current standards.
5-7: Plugin Configuration for Build Logic:
The file applies thektorbuild.project.libraryplugin, which is consistent with the new strategy for modular and isolated projects within the Ktor ecosystem.
9-18: Kotlin SourceSets and Dependency Management:
The configuration of thecommonMainandcommonTestsource sets with their respective dependencies (i.e., core server functionality and test base libraries) is well structured and supports modular development.ktor-server/ktor-server-plugins/ktor-server-content-negotiation/build.gradle.kts (3)
2-3: License Header Update:
The updated license header with the correct date range (2014-2025) is now in place.
7-9: Plugin Declaration – Server Plugin:
The inclusion of thektorbuild.project.server-pluginis consistent with the other server plugin modules, promoting uniformity across the project.
13-16: Simplified Dependency Structure:
Refactoring thecommonTest.dependenciesblock to directly list the dependency (ktor-server-double-receive) enhances readability and reduces nesting complexity.ktor-server/ktor-server-plugins/ktor-server-request-validation/build.gradle.kts (3)
2-3: License Header Update:
The updated header is consistent with the new standards (2014-2025) and correctly reflects current information.
7-9: Plugin Addition – Server Plugin:
Adding thektorbuild.project.server-pluginhere reinforces the updated, decoupled build configuration approach and aligns with the refactoring efforts across server plugin modules.
13-16: Direct Declaration of Test Dependency:
The restructuring of thecommonTest.dependenciesblock to directly declare the dependency onktor-server-status-pagesstreamlines the build script and is consistent with similar changes in other modules.ktor-server/ktor-server-plugins/ktor-server-call-id/build.gradle.kts (4)
2-2: Update Copyright Notice
The updated copyright header now reflects the range "2014-2025", which is in line with the project's current timeline.
7-9: Apply Server Plugin Declaration
The addition of thektorbuild.project.server-pluginplugin clearly signals project isolation and aligns with the PR’s objective for decoupled configuration.
13-14: Simplify commonMain Dependency Declaration
Flattening the dependency block forcommonMainimproves readability and reduces nesting. This change is consistent with the broader effort to streamline Gradle build scripts.
17-18: Streamline jvmMain Dependencies
The updated configuration that directly assigns dependencies injvmMaineliminates unnecessary nesting and maintains clarity in the build script.ktor-client/ktor-client-plugins/ktor-client-encoding/build.gradle.kts (3)
2-2: Update Copyright Notice
Updating the copyright year to "2014-2025" is appropriate and consistent with recent changes across the project.
6-6: Introduce Client Plugin Declaration
The new declaration ofktorbuild.project.client-pluginis consistent with the new modular and isolated configuration approach. This change simplifies dependency management for client plugins.
10-12: Restructure Kotlin SourceSets
The updated Kotlin block now directly declares thejvmTest.dependencieswithin thesourceSetsblock. This flattening reduces vertical nesting and makes the configuration more succinct.ktor-server/ktor-server-plugins/ktor-server-partial-content/build.gradle.kts (3)
2-2: Update Copyright Notice
The header now correctly reflects the updated time span until 2025, maintaining consistency across modules.
7-9: Standardize Server Plugin Usage
Adding thektorbuild.project.server-pluginplugin ensures uniformity across server modules and supports the isolated configuration model introduced in this PR.
13-14: Flatten commonMain Dependency Block
By directly applying the dependency configuration tocommonMain, the build script is simplified and becomes easier to maintain.ktor-http/build.gradle.kts (4)
2-2: Update Copyright Notice
The adjusted copyright range to "2014-2025" aligns with current project standards and is correctly propagated in the file.
6-6: Introduce Library Plugin
The addition of thektorbuild.project.libraryplugin supports the modular build structure improvements, enhancing clarity and project isolation.
12-15: Refine commonMain Dependencies Structure
Flattening thecommonMain.dependenciesblock to directly include dependency declarations (usingapi(...)) reduces unnecessary nesting and enhances readability.
16-19: Restructure jvmTest Dependency Block
Directly declaring dependencies in thejvmTest.dependenciesblock simplifies the script. Please verify that the scopes for these dependencies remain correct.build-logic/src/main/kotlin/ktorbuild/internal/publish/PublishTasks.kt (1)
8-8: Clarify Import Path formaybeNamed
Updating the import fromktorbuild.maybeNamedtoktorbuild.internal.gradle.maybeNamedprovides a more explicit reference to the internal package. This change improves maintainability by clarifying the origin of themaybeNamedfunction.ktor-server/ktor-server-plugins/ktor-server-status-pages/build.gradle.kts (3)
2-2: Updated Copyright Notice
The copyright notice has been updated to “2014-2025”, ensuring that the header remains accurate and current.
7-9: Introduce Server Plugin
Adding thepluginsblock withid("ktorbuild.project.server-plugin")centralizes the build configuration for server modules and aligns with the overall initiative for project isolation.
13-14: Simplify CommonTest Dependency Declaration
Refactoring thecommonTestsource set to directly access the dependencies (viacommonTest.dependencies { ... }) improves readability by removing unnecessary nesting. Ensure that the dependency onktor-server-call-idremains intact.ktor-server/ktor-server-plugins/ktor-server-metrics/build.gradle.kts (4)
2-2: Updated Copyright Notice
The header has been updated to reflect the new range (2014-2025), keeping the legal boilerplate consistent across modules.
7-9: Apply Unified Server Plugin
The addition of thepluginsblock applyingktorbuild.project.server-pluginis consistent with the refactor to isolate projects. This change helps standardize the plugin configuration across server modules.
13-16: Refined jvmMain Dependency Layout
ThejvmMain.dependenciesblock is now clearly defined, listing required Dropwizard libraries. The flattening of the dependency configuration improves clarity without changing functionality.
17-21: Updated jvmTest Dependencies
The dependencies forjvmTesthave been updated to directly reference required modules and libraries. This straightforward declaration aligns with the new build style and should be verified to ensure all modules are correctly resolved.ktor-server/ktor-server-plugins/ktor-server-pebble/build.gradle.kts (5)
2-2: Updated Copyright Notice
The copyright header now reflects “2014-2025,” which maintains consistency with other modules in the project.
5-7: Add Server Plugin Declaration for Pebble Module
Inserting thepluginsblock withid("ktorbuild.project.server-plugin")promotes a unified plugin strategy across the server modules and aids in isolating project configurations.
10-11: Restructure Kotlin Source Sets
The reorganization within thekotlin { sourceSets { ... } }block simplifies dependency declarations and improves overall readability.
11-13: jvmMain Dependency Declaration
ThejvmMainsource set now listsapi(libs.pebble)directly. This concise syntax aligns with the project’s updated dependency management style.
14-18: jvmTest Dependency Declaration
Dependencies underjvmTestare now clearly declared. Ensure that the various module dependencies (for conditional headers, compression, and content negotiation) are correctly resolved after this refactor.ktor-server/ktor-server-plugins/ktor-server-openapi/build.gradle.kts (2)
5-7: Enforce Consistent Server Plugin Usage
The newpluginsblock withid("ktorbuild.project.server-plugin")is now applied. This helps standardize the Gradle configuration across server plugins and supports the new isolated project approach.
16-22: Streamlined jvmMain Dependency Declaration
The dependencies for thejvmMainsource set are declared in a flattened and concise manner. This change simplifies maintenance while retaining all necessary dependencies, including Swagger Codegen and parser libraries.ktor-server/ktor-server-config-yaml/build.gradle.kts (3)
2-2: Updated Copyright Notice
The file’s header now correctly reflects the 2014-2025 period, keeping the legal header consistent with recent updates across modules.
5-7: Introduce Library Plugin
Using the newpluginsblock withid("ktorbuild.project.library")aligns this module with the updated project structure for libraries. This helps isolate library-specific configurations and enhances clarity.
9-16: Restructured Kotlin Source Set Configuration
The simplification of the dependency declarations withincommonMain—now directly mapping toapi(project(":ktor-server:ktor-server-core"))andapi(libs.yamlkt.serialization)—is beneficial for maintainability. Ensure that this restructuring doesn’t inadvertently alter the dependency resolution.build-logic/src/main/kotlin/ktorbuild/internal/Version.kt (1)
18-19: Improved property access using Gradle Provider APIThis change refactors property retrieval from likely using
findProperty()to using the more modernproviders.gradleProperty().orNullapproach. This is a good improvement because:
- It uses Gradle's Provider API, which enables lazy evaluation
- It integrates better with Gradle's configuration avoidance features
- It's more explicit about the source of the property
The change aligns with the PR objective of making projects isolated by ensuring properties are evaluated only when needed.
ktor-shared/ktor-websocket-serialization/build.gradle.kts (3)
2-2: Updated copyright yearThe copyright year has been updated to reflect the current timeframe.
7-9: Added project library pluginThe addition of the
ktorbuild.project.libraryplugin encapsulates common configuration for library projects. This is a good practice that:
- Reduces duplication across build scripts
- Centralizes common configuration
- Makes the build system more maintainable
This change supports the PR objective of implementing precompiled script plugins to enhance build infrastructure.
11-15: Simplified Kotlin source sets configurationThe Kotlin source sets configuration has been restructured with a flatter hierarchy for dependencies. This change:
- Improves readability by reducing nesting levels
- Aligns with Kotlin 1.9.20's
KotlinMultiplatformSourceSetConventionsmentioned in the PR objectives- Makes build scripts more maintainable
The dependencies themselves remain unchanged, preserving the existing functionality.
ktor-server/ktor-server-tomcat-jakarta/build.gradle.kts (2)
7-9: Added project library pluginThe addition of the
ktorbuild.project.libraryplugin encapsulates common configuration for library projects. This standardizes the build configuration across different modules in the project.
16-29: Simplified Kotlin source sets configurationThe source sets configuration has been improved by:
- Flattening the dependency declaration structure
- Using the direct
sourceSets.jvmMain.dependenciessyntax- Maintaining the same dependencies while improving readability
This change reduces vertical nesting in the build scripts, as mentioned in the PR objectives.
ktor-server/ktor-server-plugins/ktor-server-webjars/build.gradle.kts (4)
1-3: Added copyright noticeAdded standard copyright header to maintain consistency across project files.
7-9: Added server pluginThe addition of the
ktorbuild.project.server-pluginplugin (different from the library plugin in other files) indicates a type-specific approach to project configuration. This plugin likely encapsulates common configuration specific to server plugin projects.This change supports the PR objective of implementing precompiled script plugins and demonstrates a nuanced approach to different project types.
13-15: Simplified dependency declaration for jvmMainThe dependency structure has been simplified by directly accessing the dependencies property of jvmMain, reducing unnecessary nesting. The dependencies themselves remain unchanged.
16-20: Simplified dependency declaration for jvmTestSimilarly, the test dependencies structure has been simplified by using the direct
jvmTest.dependenciessyntax, which improves readability while maintaining the same dependencies.ktor-server/ktor-server-jetty/build.gradle.kts (3)
7-9: Plugin Addition for Project Isolation
The inclusion ofid("ktorbuild.project.library")ensures that the module adheres to the new isolated configuration model. This change simplifies project settings consistently with the PR objectives.
13-22: StreamlinedjvmMainDependency Declaration
Refactoring thejvmMaindependencies to the concise.dependencies { ... }syntax minimizes nesting and enhances readability while retaining the original dependency list.
23-29: ConsistentjvmTestDependency Format
Updating thejvmTestblock to use the new DSL format improves consistency across modules and simplifies maintenance of test dependencies.ktor-server/ktor-server-cio/build.gradle.kts (3)
7-9: Plugin Injection for Modular Configuration
The newly addedid("ktorbuild.project.library")plugin correctly initiates the self-contained project setup, aligning with the goal to decouple project configurations.
11-18: Direct Dependency Declaration incommonMain
UtilizingcommonMain.dependencies { ... }eliminates unnecessary nesting while declaring dependencies, which enhances clarity and adherence to the updated Gradle script style.
19-23: CleancommonTestDependency Block
The refactoredcommonTest.dependencies { ... }maintains dependency consistency and improves readability, perfectly fitting the isolated projects objective.ktor-client/ktor-client-apache5/build.gradle.kts (3)
7-10: Enhanced Plugin Configuration
Adding thektorbuild.project.libraryplugin alongside the existingtest-serverplugin reinforces the module’s build isolation and modernizes the dependency management.
12-16: ConcisejvmMainDependency Setup
Switching to a directjvmMain.dependencies { ... }syntax reduces verbosity and aligns this module with the updated DSL conventions seen in other modules.
18-20: Refactored Test Dependency Declaration
The streamlined declaration forjvmTest.dependenciesenhances clarity and maintains consistency with the overall refactor approach for dependency management.ktor-server/ktor-server-plugins/ktor-server-thymeleaf/build.gradle.kts (3)
5-7: Server Plugin Integration
Introducing thektorbuild.project.server-pluginis appropriate for this module. It clearly demarcates server-side plugin functionality and promotes isolated project configuration.
9-13: RefinedjvmMainDependency Listing
The direct configuration underjvmMain.dependencies { ... }minimizes nesting while preserving the intended dependencies, resulting in a cleaner build script.
14-18: UnifiedjvmTestDependency Structure
The updated block forjvmTest.dependencies { ... }follows the same concise style as the main source set, ensuring consistency across the project and easier maintenance.ktor-shared/ktor-serialization/build.gradle.kts (2)
7-9: Library Plugin Application
The addition ofid("ktorbuild.project.library")reinforces the concept of self-contained modules. This change is consistent with the overall strategy for isolating projects in the build configuration.
11-17: SimplifiedcommonMainDependencies
Moving to a directcommonMain.dependencies { ... }structure reduces complexity in the DSL and aligns with the new streamlined approach applied across the project.ktor-client/ktor-client-plugins/ktor-client-tracing/build.gradle.kts (2)
5-7: Plugin Declaration for Isolation
Thepluginsblock now addsktorbuild.project.client-plugincorrectly. This adheres to the new isolated project configuration strategy and is consistent with the broader PR objectives.
9-18: Streamlined SourceSets Configuration
Thekotlin { sourceSets { ... } }block is reorganized to define dependencies directly insidecommonMainandjvmTest. The direct declaration (without extra nesting) improves clarity and maintainability while preserving the intended dependency relationships.ktor-client/ktor-client-js/build.gradle.kts (2)
5-7: Library Plugin Usage
The file now applies thektorbuild.project.libraryplugin. This change is appropriate given the refactoring goals of isolating project configurations and aligning with the new dependency declaration syntax.
10-19: Simplified Dependency Declarations
Thekotlin { sourceSets { ... } }configuration for bothjsMainandwasmJsMainhas been simplified by removing the extra nested blocks. Declaring dependencies directly within the source sets is aligned with the PR’s objective to reduce nesting and enhance readability.ktor-shared/ktor-serialization/ktor-serialization-gson/build.gradle.kts (2)
7-9: Consistent Application of the Library Plugin
The addition of thektorbuild.project.libraryplugin ensures that this module now follows the standardized configuration. This change is in line with other modules and supports the isolation strategy proposed in the PR.
11-26: Refined Kotlin SourceSets Structure
The restructuredkotlin { sourceSets { ... } }block now directly declares dependencies forjvmMainandjvmTest, which reduces vertical nesting and simplifies the script. This improved readability and maintainability meets the PR’s goals, and the dependency mappings (e.g., usingapi(project(...))andapi(libs.gson)) remain correct.ktor-client/ktor-client-android/build.gradle.kts (2)
7-10: Enhanced Plugin and Test Configuration
Addingktorbuild.project.libraryalongsidetest-serverin thepluginsblock supports both the new isolated project configuration and the testing infrastructure. This clear separation of concerns is a positive step forward.
12-23: Streamlined SourceSets with Direct Dependency Declarations
The new structure forkotlin { sourceSets { ... } }simplifies dependency declarations forjvmMainandjvmTest. This change reduces unnecessary nesting while preserving all intended project dependencies, which is in line with the PR objectives.build-logic/src/main/kotlin/ktorbuild.publish.verifier.gradle.kts (4)
5-8: Updated Imports for Publish Verification
The updated import section (lines 5–8) now clearly brings in the necessary components fromktorbuildand its internal publish packages. This aligns with the new logic that focuses on published projects.
10-12: Clean Test Repository Setup
The task registration forcleanTestRepositoryis maintained properly. The use oflocateTestRepository()in the delete directive remains clear and consistent with the testing requirements.
14-15: Introduction of Published Projects Variable
The new variablepublishedProjects(lines 14–15) retrieves projects tagged withProjectTag.Published. This targeted approach is an effective refactoring to limit validations and configurations to only the necessary subset of projects.
16-28: Validation Task Refactoring for Published Projects
TheValidatePublishedArtifactsTaskis now configured to depend oncleanTestRepositoryand iterates overpublishedProjectsto configure the test repository and publish task dependencies. This refactoring streamlines the publish verification process by focusing only on projects marked as published, which is a key improvement promoting project isolation.ktor-server/ktor-server-plugins/ktor-server-auth/build.gradle.kts (4)
2-2: Copyright Notice Updated.
The copyright header now reflects "2014-2025", ensuring the file is up to date.
8-8: Server Plugin Declaration Added.
The addition ofid("ktorbuild.project.server-plugin")aligns with the project isolation goals and standardizes the plugin usage across the server modules.
14-17: Simplified CommonMain Dependencies.
Defining dependencies directly viacommonMain.dependenciesimproves readability by reducing nested blocks. Confirm that the referenced projects and libraries (such asktor-client-core,ktor-server-sessions, andlibs.kotlinx.serialization.json) are accurate across modules.
19-21: Streamlined jvmTest Dependencies.
The refactored jvmTest block now cleanly lists dependencies, which helps maintain consistency with other modules. Ensure that the dependency targets are current and correctly configured.ktor-client/ktor-client-plugins/ktor-client-content-negotiation/build.gradle.kts (3)
2-2: License Year Updated.
The header now uses "2014-2025" to correctly reflect the current copyright period.
8-8: Client Plugin Declaration Added.
Introducingid("ktorbuild.project.client-plugin")is consistent with the shift toward isolated and self-contained module configurations.
14-15: Refined CommonMain Dependency Configuration.
Moving to a direct dependency declaration (commonMain.dependencies) simplifies the build script. Verify that the dependency on:ktor-shared:ktor-serializationmeets the new configuration standards.build.gradle.kts (1)
12-12: Kotlin Version Print Statement Simplified.
The print statement is now concise—displaying"Kotlin version: ${libs.versions.kotlin.get()}"instead of the earlier verbose message. This change enhances clarity while preserving functionality.ktor-server/ktor-server-plugins/ktor-server-call-logging/build.gradle.kts (4)
2-2: Copyright Update.
The copyright header has been updated to "2014-2025," aligning with the current standards.
7-9: Server Plugin Applied.
The newpluginsblock now cleanly applies thektorbuild.project.server-plugin, reinforcing the refactoring effort toward project isolation.
13-16: Clear jvmMain Dependencies.
Dependencies forjvmMainare now declared directly, improving the script’s readability. Ensure that libraries (likelibs.jansiandlibs.kotlinx.coroutines.slf4j) are at the correct versions.
18-21: Updated jvmTest Dependency Declarations.
Directly setting dependencies forjvmTeststreamlines this section; check that the project references forktor-server-call-idandktor-server-status-pagesaccurately reflect the current module structure.ktor-shared/ktor-sse/build.gradle.kts (3)
2-2: License Header Revised.
The copyright notice has been updated to "2014-2025," ensuring the file is current.
7-9: Library Plugin Declaration Introduced.
Addingid("ktorbuild.project.library")signals that this module is now managed as a library, which helps standardize the build configuration across the project.
11-16: Streamlined SourceSet Dependency Definition.
Defining dependencies directly withincommonMain.dependenciesreduces nesting and enhances clarity. Verify that the dependency on:ktor-utilsis correctly maintained in the new setup.ktor-server/ktor-server-plugins/ktor-server-html-builder/build.gradle.kts (1)
9-18: Updated Kotlin DSL StructureMoving the source set configuration into the dedicated
kotlin { sourceSets { … } }block improves readability and maintainability. Confirm that the dependency declarations (such asapi(libs.kotlinx.html)forcommonMainand the status pages project dependency incommonTest) are fully validated with the new project isolation approach.ktor-server/ktor-server-plugins/ktor-server-mustache/build.gradle.kts (2)
5-7: Consistent Plugin DeclarationThe inclusion of
ktorbuild.project.server-pluginis consistent with the server module refactoring. This reinforces the shared configuration structure among the server plugins.
9-20: Refactored SourceSet StructureThe restructuring of the Kotlin DSL into a clear
kotlin { sourceSets { … } }block enhances clarity. Double-check that all inter-project dependencies (e.g., those for Mustache, Compression, Conditional Headers, and Content Negotiation) continue to resolve correctly under the new configuration scheme.ktor-client/ktor-client-plugins/ktor-client-call-id/build.gradle.kts (2)
7-9: Client Plugin DeclarationThe new application of
ktorbuild.project.client-pluginis appropriate for this module. Ensure that its semantics and configuration requirements are well-documented, matching the expectations across similar client projects.
11-21: Refactored Kotlin DSL for SourceSetsRefactoring the source sets to the streamlined Kotlin DSL format clarifies dependency management. It’s important to verify that the dependency references (like
project(":ktor-shared:ktor-call-id")incommonMainand the server-related dependencies incommonTest) accurately reflect the intended modular boundaries.ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-tests/build.gradle.kts (2)
5-8: Internal Plugin Update and SerializationThe addition of the
ktorbuild.project.internalplugin alongsidekotlinx-serializationreinforces a clear separation for internal project components. Ensure that this internal plugin’s configuration does not inadvertently expose settings outside the intended scope.
10-23: Streamlined SourceSets ConfigurationReorganizing the
sourceSetsblock into the new Kotlin DSL format simplifies dependency management. Validate that dependencies for bothcommonMain(including test annotations and primary serialization libraries) andjvmMain(with logging frameworks) function as expected in the isolated project structure.ktor-client/ktor-client-apache/build.gradle.kts (2)
7-10: Library Plugin ConsistencyThe switch to using
ktorbuild.project.librarymarks this module as a library, and its combination with thetest-serverplugin should be reviewed to ensure clear separation of library code and test configurations. Verify that both plugins’ responsibilities are well-documented.
12-22: Updated Dependency Management in SourceSetsThe refactored Kotlin DSL for defining
sourceSetsconsolidates dependency configuration, making it more legible. Confirm that the dependencies underjvmMain(for the client core and Apache HTTP async client) andjvmTestare correctly scoped and that no transitive dependency conflicts arise from this restructuring.ktor-client/ktor-client-plugins/ktor-client-websockets/build.gradle.kts (2)
1-3: Updated Copyright Notice
The header now correctly reflects the new copyright range ("2014-2025") in line with the update.
5-7: Added Client Plugin Declaration
The newly added pluginktorbuild.project.client-pluginclearly signals the module’s role as a client component and supports the goal of making projects isolated.ktor-server/ktor-server-plugins/ktor-server-sessions/build.gradle.kts (3)
1-3: Updated Copyright Notice
The updated header with "2014-2025" is consistent with current policy and reflects the necessary update.
7-10: Added Server Plugin and Organized Plugins
Introducing thektorbuild.project.server-plugin(line 8) helps in isolating and standardizing the server module. The inclusion ofkotlinx-serializationimmediately afterwards is clear and appropriate.
12-22: Streamlined Dependency Declaration
The configuration within thekotlinblock now directly assigns dependencies tocommonMainandjvmTest, eliminating extra nesting. This simplification should improve maintainability while keeping functionality intact.ktor-client/ktor-client-jetty/build.gradle.kts (3)
1-3: Updated Copyright Notice
The copyright header now reflects "2014-2025", which is appropriate for the current version.
7-9: New Library Plugin Declaration
Adding thektorbuild.project.libraryplugin isolates the configuration for the Jetty client engine and supports the overall modularization goals.
11-24: Refactored Kotlin DSL Dependency Blocks
The newkotlinblock structure cleanly segregates thejvmMainandcommonTestdependencies, making the script more readable and easier to maintain.ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-gson/build.gradle.kts (3)
1-3: Updated Copyright Notice
The header reflects the updated copyright period ("2014-2025"), which is consistent throughout the repository.
5-7: Client Plugin Added
The declaration ofktorbuild.project.client-pluginat the top aligns with the new isolated project approach. This change simplifies the configuration and maintains consistency with other client modules.
9-20: Streamlined Kotlin DSL Structure
The simplifiedkotlinblock now defines source set dependencies directly underjvmMainandjvmTest. This more concise declaration aids in clarity and maintainability. Double-check that all declared dependencies (e.g., for Gson and related modules) resolve correctly with the new syntax.ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-jackson/build.gradle.kts (3)
1-3: Updated Copyright Notice
The updated header is correct and now reflects the new copyright period ("2014-2025").
5-7: Consistent Plugin Declaration
The addition ofktorbuild.project.client-pluginis consistent with other client modules and supports the isolation of project configurations.
9-23: Optimized Kotlin DSL Dependency Configuration
The refactoring of thekotlinblock simplifies dependency declarations acrossjvmMainandjvmTest. This cleaner approach enhances readability and maintains consistency. Please verify that all dependencies (like Jackson libraries and the testing modules) integrate as expected in the new structure.ktor-shared/ktor-resources/build.gradle.kts (1)
1-10: Plugin Addition & Copyright
The top of the file now includes an updated copyright notice and adds the
ktorbuild.project.libraryplugin in the plugins block. This clearly aligns
with the PR objective of isolating project configurations. Ensure that this
plugin is used consistently across modules.ktor-server/ktor-server-jetty/ktor-server-jetty-test-http2/build.gradle.kts (1)
7-9: Internal Plugin Introduction
The introduction of thektorbuild.project.internalplugin in the plugins block helps
differentiate the internal project artifacts. Verify that this usage does not conflict
with plugins in aggregating projects and aligns with the lazy evaluation strategy.ktor-shared/ktor-test-base/build.gradle.kts (3)
7-9: Internal Plugin Application
The use of thektorbuild.project.internalplugin is applied here, which reinforces
internal build configurations consistently across the Ktor modules.
11-17: Enhancement of commonMain Dependencies
Addingapi(project(":ktor-utils"))to thecommonMain.dependenciesblock enriches
the module’s modularity by ensuring shared utilities are available. Confirm that
this addition does not introduce any circular dependency issues.
19-24: Clear JVM Main Dependency Declarations
Splitting out dependencies forjvmMaininto its own block enhances the configurability
and clarity of module-specific dependencies. This approach is consistent with similar refactors.ktor-client/ktor-client-cio/build.gradle.kts (5)
1-3: Copyright Update
Updating the copyright year to 2025 correctly reflects the current timeline of
the project’s development.
7-10: Plugin Declaration Consistency
The inclusion ofktorbuild.project.libraryin the plugins block helps standardize
library project configurations. This change follows the broader effort across the modules.
14-19: Refactored commonMain Dependencies
The dependency declarations undercommonMain.dependenciesare now more concise.
Ensure that the reordering or flattening does not affect dependency resolution.
20-22: commonTest Dependencies Restructuring
Flattening the dependency declaration withincommonTest.dependenciesmakes the DSL
easier to scan and consistent with the overall approach.
23-27: jvmTest Dependencies Refinement
The reorganization ofjvmTest.dependenciesinto a more structured format improves
readability and maintainability. Verify that all required test dependencies are present
and correctly configured.build-logic/src/main/kotlin/ktorbuild.base.gradle.kts (1)
10-11: ProjectTagsService Registration
Registering the project withProjectTagsService.register(project)is a key addition that
supports the lazy evaluation and synchronizes project tags as outlined in the PR objectives.
This setup should be monitored to ensure that it integrates seamlessly with the existing
build lifecycle.ktor-client/ktor-client-winhttp/build.gradle.kts (3)
8-8: Consistent Library Plugin Addition
The new plugin declarationid("ktorbuild.project.library")is added as intended to help isolate the project. This aligns well with the PR objectives.
17-20: Streamlined Dependency Declaration for windowsMain
The refactored dependency block forwindowsMainnow directly uses the dot notation. The dependencies remain unchanged and the syntax is much clearer.
21-25: Clean Dependency Block for windowsTest
The changes refactor thewindowsTestdependency declarations into a concise form. All references to projects are preserved, and the structure is consistent with similar modules.ktor-server/ktor-server-plugins/ktor-server-auth-jwt/build.gradle.kts (2)
5-7: Appropriate Server Plugin Usage
The addition of the server pluginid("ktorbuild.project.server-plugin")is consistent with the PR’s goal to isolate project configurations.
9-19: Concise SourceSets and Dependency Blocks
The updated Kotlin DSL for thesourceSets(both forjvmMainandjvmTest) is clear and simplifies dependency declarations. Dependency references (includinglibs.java.jwtandlibs.jwks.rsa) are maintained correctly.ktor-http/ktor-http-cio/build.gradle.kts (4)
7-9: Plugin Declaration for Library Module
The newktorbuild.project.libraryplugin is added to this module to ensure its configuration is isolated. This change is consistent with similar updates across the project.
11-16: Simplified CommonMain Dependencies
The block forcommonMain.dependenciesnow uses a cleaner dot notation. The dependencies onproject(":ktor-http")andproject(":ktor-io")appear correct. It might be beneficial to quickly verify that these project paths still resolve as expected.
18-20: Clear jvmMain Dependency Specification
ThejvmMain.dependenciesblock is refactored effectively with a concise syntax (declaring the dependency onproject(":ktor-network")).
22-24: Clean and Concise jvmTest Dependencies
The dependency declaration forjvmTestis straightforward and maintains the intended dependency onlibs.kotlinx.coroutines.test.ktor-server/ktor-server-plugins/ktor-server-auth-ldap/build.gradle.kts (3)
5-7: Server Plugin Applied Correctly
The file now explicitly applies thektorbuild.project.server-plugin, which is in line with establishing isolated project configurations for server components.
9-13: Refined jvmMain Dependency Declaration
ThejvmMain.dependenciesblock is streamlined, and the dependency onproject(":ktor-server:ktor-server-plugins:ktor-server-auth")remains intact. Verify that this module reference is still correct within the overall project structure.
14-17: Consistent jvmTest Dependencies for LDAP Authentication
ThejvmTest.dependenciesblock clearly lists the required ApacheDS libraries. The structure and dependencies are consistent with expectations.ktor-server/ktor-server-servlet-jakarta/build.gradle.kts (3)
7-9: Library Plugin Application for Servlet Module
The new plugin declarationid("ktorbuild.project.library")is now applied for this module. This ensures isolation and standardizes the build configuration across modules.
11-13: Preserved JVM Toolchain Configuration
ThektorBuildblock specifyingjvmToolchain(11)remains unchanged and correctly supports the module’s requirements.
15-29: Refactored and Readable Kotlin SourceSets Block
The transformation of thesourceSetsblock into a concise structure for bothjvmMainandjvmTestis clear and improves readability. Notably, thejvmMainblock correctly includes an API dependency on":ktor-server:ktor-server-core"and markslibs.jakarta.servletascompileOnly, which is typical for servlet APIs provided at runtime. Meanwhile, thejvmTestblock properly lists implementation dependencies.ktor-server/ktor-server-test-host/build.gradle.kts (4)
7-9: Plugin Configuration Update:
The introduction ofid("ktorbuild.project.library")in the plugins block clearly aligns with the PR objective by enabling isolated, self-contained project setups through precompiled script plugins.
11-18: Streamlined CommonMain Dependencies:
Restructuring the Kotlin DSL to declarecommonMain.dependenciesdirectly inside thesourceSetsblock reduces unnecessary nesting and improves readability. This change simplifies maintenance and preserves clarity in dependency declaration.
20-34: Updated jvmMain Dependencies Block:
The revised formatting for thejvmMain.dependenciesblock aligns with the new streamlined structure. The inline comment regarding the inclusion of the websockets artifact is informative. Consider exploring alternatives in the future if the trade-off regarding artifact size becomes a concern.
36-39: Modernized jvmTest Dependencies:
The simplified declaration for thejvmTest.dependenciesblock enhances consistency within the build script. The dependency configuration is now clear and concise.ktor-client/ktor-client-plugins/ktor-client-resources/build.gradle.kts (2)
7-10: Client Plugin Update:
Adding theid("ktorbuild.project.client-plugin")to the plugins block precisely categorizes this module as a client plugin. This change supports decoupled, isolated configurations as envisioned in the PR objectives.
12-18: Simplified Kotlin Configuration:
The restructuring of the Kotlin DSL to directly nestcommonMain.dependenciesreduces vertical nesting and declutters the build script. This improved layout makes the dependency declarations easier to follow and maintain.ktor-client/ktor-client-test-base/build.gradle.kts (2)
7-9: Internal Plugin Addition:
The newpluginsblock inclusion ofid("ktorbuild.project.internal")clearly distinguishes internal modules and standardizes dependency management, which is beneficial for isolated project builds.
11-18: Flattened SourceSet Structure:
The refactoring of the Kotlin DSL by flattening the source set definitions (i.e.commonMain.dependenciesdirectly withinsourceSets) eliminates extra nesting levels and leads to clearer, more maintainable build scripts.build-logic/src/main/kotlin/ktorbuild.doctor.gradle.kts (1)
26-26: Robust Property Access:
Switching from a directfindPropertyapproach to usingproviders.gradleProperty("doctor.enableTaskMonitoring").orNull.toBoolean()leverages Gradle’s Providers API, making property retrieval more robust and aligned with best practices.ktor-server/ktor-server-plugins/ktor-server-resources/build.gradle.kts (2)
7-10: Server Plugin Configuration:
The addition ofid("ktorbuild.project.server-plugin")in the plugins block unmistakably designates this module as part of the server plugin set. This explicit declaration supports modular configuration and consistent build practices across projects.
12-18: Optimized Kotlin DSL Structure:
Reformatting the Kotlin DSL to accesscommonMain.dependenciesdirectly simplifies the dependency declaration process. This refined structure promotes clarity and reduces redundancy in the build script.ktor-server/ktor-server-plugins/ktor-server-sse/build.gradle.kts (3)
1-4: Updated Header Information
The updated copyright notice now reflects the correct year range (2014–2025) and license information. This keeps the metadata consistent with project standards.
7-10: Addition of Server Plugin
Introducingid("ktorbuild.project.server-plugin")in the plugins block is key for isolating the module configuration. This aligns well with the PR’s objective of decoupling projects.
12-22: Streamlined SourceSets Configuration
Flattening the source set structure into direct dependency declarations (for bothcommonMainandcommonTest) reduces nesting and improves readability. Verify that all dependency paths still resolve correctly.ktor-server/ktor-server-core/build.gradle.kts (2)
9-12: Incorporation of Library Plugin
The new plugin declaration withid("ktorbuild.project.library")clearly signals that this module is self-contained. This change is consistent with the overall strategy to isolate individual projects.
17-43: Enhanced Dependency Declaration in SourceSets
Refactoring the dependency declarations forcommonMain,jvmMain,commonTest, andjvmTestsimplifies maintenance and aligns with Kotlin DSL best practices. Confirm that the reorganized dependencies continue to cover all required modules.ktor-server/ktor-server-test-base/build.gradle.kts (2)
7-10: Utilization of Internal Plugin for Test Base
Applyingid("ktorbuild.project.internal")in the plugins block correctly categorizes this module as internal. This is in line with the intended refactoring to further isolate project configurations.
11-28: Simplified SourceSets for Testing Dependencies
The consolidation of dependencies within thecommonMainandjvmMainsource sets reduces unnecessary nesting. This makes the configuration easier to read and maintain without altering dependency semantics.ktor-server/ktor-server-plugins/ktor-server-jte/build.gradle.kts (2)
5-8: Server Plugin Integration for JTE Module
Addingid("ktorbuild.project.server-plugin")ensures that the server JTE module adheres to the isolated project model. This change is aligned with the refactoring goals.
14-27: Refined Kotlin DSL for Dependency Management
The restructuredkotlin { sourceSets { ... } }block—covering bothjvmMainandjvmTest—offers a cleaner, more maintainable way to declare dependencies. All dependencies remain present and correctly grouped.ktor-client/ktor-client-plugins/ktor-client-json/ktor-client-serialization/build.gradle.kts (3)
1-4: Updated Copyright Metadata
The header now properly reflects the current copyright timeline (2014–2025), ensuring all files are up-to-date.
5-9: Addition of Client Plugin Declaration
Introducingid("ktorbuild.project.client-plugin")in the plugins block properly categorizes this module as a client-specific component. This aligns with the overall refactoring toward isolated, self-contained project configurations.
10-17: Optimized SourceSet Dependency Declaration
The updated Kotlin DSL structure withkotlin { sourceSets { ... } }removes extra nesting and clarifies dependency references (e.g.,libs.kotlinx.serialization.jsonand the relevant project dependency). This contributes to improved readability and maintainability.ktor-server/ktor-server-test-suites/build.gradle.kts (3)
7-9: Added appropriate plugin for internal project structureThis addition of the
ktorbuild.project.internalplugin aligns with the PR objective of implementing precompiled script plugins for better build infrastructure and project isolation.
11-13: Improved source sets configuration structureThe new structure for Kotlin source sets follows the updated syntax pattern introduced in Kotlin 1.9.20, reducing vertical nesting and making the build script more concise.
22-22: Simplified dependency declaration for jvmMainThe restructured jvmMain dependencies block follows the same improved pattern, enhancing readability while maintaining the same dependency relationships.
ktor-client/ktor-client-plugins/ktor-client-content-negotiation/ktor-client-content-negotiation-tests/build.gradle.kts (2)
8-8: Added ktorbuild.project.internal pluginThis addition enforces consistent project structure and configuration, supporting the PR goal of making projects more isolated and self-contained.
12-23: Restructured sourceSets configuration for better readabilityThe change adopts the new pattern for Kotlin multiplatform source set configuration that reduces nesting and improves readability while maintaining the same dependencies. This is consistent with the changes made in other module build scripts.
build-logic/src/main/kotlin/ktorbuild/internal/gradle/Property.kt (3)
7-12: Added necessary imports for file provider utilitiesThese imports support the new directory and file provider extension functions, which are essential for the implementation of lazy evaluation mentioned in the PR objectives.
16-18: Added directoryProvider extension functionThis function creates a
Provider<Directory>from a file provider lambda, enabling lazy resolution of directory references. This supports the PR goal of refactoring aggregating projects to utilize Lazy APIs.
19-20: Added regularFileProvider extension functionSimilar to the directoryProvider function, this utility creates a
Provider<RegularFile>from a file provider lambda, furthering the implementation of lazy evaluation for file references.build-logic/src/main/kotlin/ktorbuild.publish.gradle.kts (2)
5-6: Updated import statements for better organizationChanged from a specific import to a wildcard import for the ktorbuild package while maintaining a specific import for the internal gradle findByName function, improving code organization.
17-17: Implemented project tagging for published projectsThis addition integrates with the new
ProjectTagServicementioned in the PR objectives, which synchronizes evaluation between aggregating and ordinary projects. Tagging this script as "Published" ensures proper coordination with other tagged projects.ktor-server/ktor-server-jetty-jakarta/build.gradle.kts (3)
7-9: Plugin Addition for Isolation
The addition of thektorbuild.project.libraryplugin helps to isolate this module’s configuration and enforces a consistent build setup across projects.
18-27: Streamlined jvmMain Dependency Declaration
The dependencies underjvmMainare now declared directly via thedependenciesproperty. This flattening of the structure improves clarity and aligns with the objective of reducing vertical nesting in build scripts.
28-35: Consistent jvmTest Dependency Configuration
Defining thejvmTestdependencies directly supports a more readable and uniform configuration. All declared dependencies appear consistent with other modules in the project.ktor-client/ktor-client-curl/build.gradle.kts (3)
7-11: Unified Plugin Configuration
The plugin block now includesktorbuild.project.libraryalongside other plugins. This change enforces consistent project configuration isolation across modules while retaining essential functionality (e.g.,kotlinx-serializationandtest-server).
20-23: Refined Dependency Declaration for desktopMain
The direct declaration of dependencies in thedesktopMainsource set (using itsdependenciesproperty) simplifies the configuration. The referenced projects and libraries are correctly declared.
24-29: Consistent Dependency Declaration for desktopTest
ThedesktopTestsource set now declares dependencies directly, ensuring clarity. The mix ofimplementationandapiconfigurations appears properly set up as per the project’s dependency requirements.ktor-bom/build.gradle.kts (5)
5-6: Importing Custom Build Logic
Importing all definitions fromktorbuild.*ensures that custom Gradle extensions and helper functions are available. This change supports the new dependency constraint features introduced later in the file.
7-11: Base Plugin Integration for BOM Configuration
The inclusion of thektorbuild.baseplugin standardizes the build infrastructure for the BOM module. Combined withjava-platformandmaven-publish, it modernizes the project configuration.
19-21: Deferred Publication Plugin Application
Applying thektorbuild.publishplugin after the publications are configured (as noted by the inline comment) is a correct approach. It ensures that the publishing process can accurately reference the complete configuration.
22-28: Dynamic Collection of Library Publications
The newallPublicationsdeclaration usesprojectsWithTag(ProjectTag.Library)to collect, filter, and transform library project publications. This refactoring simplifies dependency constraint management and reduces manual upkeep.
30-32: Lazy Addition of Dependency Constraints
UsingdependencyConstraints.addAllLater(allPublications)allows for a lazy and dynamic configuration of API constraints. This approach improves build time determinism and modularity.ktor-shared/ktor-serialization/ktor-serialization-tests/build.gradle.kts (2)
5-8: Internal Plugin for Test Modules
The addition of thektorbuild.project.internalplugin indicates this module is intended for internal use. This aids in isolating implementation details while still supporting necessary functionalities like Kotlin serialization.
10-19: Refined Dependency Declaration in Source Sets
Restructuring thekotlinblock to directly usesourceSets(withjvmMain.dependencies) creates a cleaner and more maintainable configuration. The dependencies, including the newly added test integration for content-negotiation, align with the new build configuration strategy.ktor-server/ktor-server-plugins/ktor-server-default-headers/build.gradle.kts (4)
9-11: Server Plugin Integration
Introducing thektorbuild.project.server-pluginplugin in this module centralizes server-specific configurations. This makes the module more self-contained and adheres to the isolated projects objective.
15-17: Streamlined CommonMain Dependency Declaration
The update to define dependencies directly viacommonMain.dependenciesenhances readability and consistency with other modules. The inclusion oflibs.kotlinx.datetimeis correctly positioned and requires no further changes.
21-52: Version File Generation Task Remains Consistent
ThegenerateKtorVersionFiletask is well defined and leverages dynamic properties (such as the current year) to keep version information current. The use of lazy task registration and dependency onprepareKotlinIdeaImportfollows best practices.
53-59: Dynamic Source Directory Inclusion for Generated Code
Adding the generated sources directory to thecommonMainsource set viakotlin.srcDir(generateKtorVersionFile)ensures that the dynamically generated version file is included in the compilation process. This integration is clean and follows established conventions.ktor-server/build.gradle.kts (2)
7-9: Improved project isolation with library pluginThe addition of the
ktorbuild.project.libraryplugin aligns with the PR objective of making projects isolated and self-contained. This standard plugin application replaces custom configuration code that was likely previously scattered throughout the build scripts.
11-18: Simplified source set configurationThe updated syntax for Kotlin source set configuration is cleaner and more concise. This change:
- Removes nested block structure
- Uses the
.dependenciesproperty directly- Maintains the same dependency relationships
This aligns with the PR objective of reducing vertical nesting in build scripts while making each project self-contained.
ktor-server/ktor-server-tomcat/build.gradle.kts (2)
7-9: Standardized plugin applicationThe addition of the
ktorbuild.project.libraryplugin standardizes this module's configuration with the rest of the project, supporting better project isolation.
11-24: Improved DSL structure for source setsThe refactored source set configuration uses a more concise syntax while maintaining the same dependencies. This aligns with the PR's goal of simplifying configuration and reducing nesting in build scripts.
ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-xml/build.gradle.kts (3)
2-2: Updated copyright yearThe copyright year has been updated to 2025, keeping the license notice current.
5-8: Added library plugin while preserving serialization pluginThe
ktorbuild.project.libraryplugin has been added while maintaining the existingkotlinx-serializationplugin. This ensures standardized project configuration without losing specialized functionality.
10-22: Streamlined source set configurationThe Kotlin source set configuration has been refactored to use direct dependency declaration syntax, which is more concise and consistent with the other modules. This supports the PR's goal of standardizing build configuration across the project.
ktor-client/ktor-client-jetty-jakarta/build.gradle.kts (2)
7-9: Standardized project configurationThe addition of the
ktorbuild.project.libraryplugin brings this module in line with the standardized build configuration, supporting project isolation.
16-28: Simplified source set DSLThe refactored Kotlin DSL syntax for source sets is more concise while maintaining the same dependencies. This change supports the PR's goal of simplifying build configuration and reducing nesting.
build-logic/src/main/kotlin/ktorbuild/targets/JvmConfig.kt (3)
7-8: Added imports for project taggingThese imports support the new project tagging feature, which is essential for the PR's goal of implementing isolated projects and enabling configuration on demand.
22-22: Added JVM project taggingThis line registers the project with the
ProjectTag.Jvmtag, which enables theProjectTagServiceto track and synchronize evaluation between projects with different roles (e.g., aggregating vs. ordinary projects). This is a key part of the PR's objective to implement isolated projects with proper evaluation ordering.
105-109: Stricter module naming convention enforcementThe implementation has been improved to:
- Strictly enforce that project names must start with "ktor-" prefix using
check- Simplify the module name generation logic
This change ensures consistent naming conventions across the project, which is important for module resolution and compatibility.
ktor-shared/ktor-serialization/ktor-serialization-kotlinx/build.gradle.kts (2)
7-10: Refined Plugin Declaration.
The addition ofid("ktorbuild.project.library")alongside the existingkotlinx-serializationplugin supports the new isolated project strategy and correctly marks this module as a library.
12-19: Modernized Source Sets Configuration.
Refactoring the source sets into thekotlin { sourceSets { ... } }block improves clarity and consistency with the new Kotlin DSL guidelines adopted across the project.ktor-server/ktor-server-jetty-jakarta/ktor-server-jetty-test-http2-jakarta/build.gradle.kts (2)
7-9: Updated Internal Plugin Usage.
The declaration ofid("ktorbuild.project.internal")is appropriate for this module, reinforcing the isolation mechanism for internal configurations within the project.
16-26: Cleaned Kotlin DSL for Test Dependencies.
The restructuring of thejvmTestsource set dependencies under thekotlin { sourceSets { ... } }block enhances readability and maintainability, making the dependencies explicit and neatly organized.ktor-utils/build.gradle.kts (2)
7-10: Consolidated Plugin and Serialization Declarations.
Addingid("ktorbuild.project.library")together withid("kotlinx-serialization")ensures this module aligns with the project’s new isolated structure and continues to support serialization functionality effectively.
26-37: Streamlined Dependency Declarations in Source Sets.
The updated structure forcommonMain,commonTest, andjvmTestdependencies under thesourceSetsblock is clear and consistent with the new DSL style, reducing nesting and potential confusion.ktor-client/ktor-client-okhttp/build.gradle.kts (3)
2-3: Updated Copyright Notice.
The copyright header has been updated to 2025, ensuring that the file's attribution information stays current.
5-8: Consistent Library Plugin Integration.
The addition ofid("ktorbuild.project.library")in the plugin block supports the refactoring objectives by clearly delineating this module as a library project, while the inclusion of thetest-serverplugin remains intact.
10-22: Simplified Kotlin Source Sets Configuration.
Transitioning to the concisekotlin { sourceSets { ... } }DSL structure for declaring dependencies injvmMainandjvmTesthelps reduce vertical complexity and enhances overall readability.ktor-client/ktor-client-plugins/ktor-client-logging/build.gradle.kts (3)
2-3: Updated Copyright Notice.
The copyright header is now updated for 2025, keeping the license information accurate and current.
5-7: Appropriate Client Plugin Declaration.
Switching to thektorbuild.project.client-pluginfor this module aligns with the architectural changes intended for client plugins, enhancing modularity and consistency across the Ktor client modules.
9-24: Refined Source Sets Structure for Dependencies.
The restructuring of dependency declarations forjvmMain,commonTest, andjvmTestunder a unifiedsourceSetsblock improves clarity, reduces nesting, and follows the updated Kotlin DSL syntax—this promotes better maintainability and consistency.ktor-server/ktor-server-plugins/ktor-server-metrics-micrometer/build.gradle.kts (2)
1-7: License and Plugin Declaration ApprovedThe updated license header and the application of the
ktorbuild.project.server-pluginin the plugins block are correct and align with the standardized build configuration.
11-16: Streamlined Dependency DeclarationsThe dependency block within the
kotlin { sourceSets { ... } }section is clear and concise. BothjvmMainandjvmTestdependencies are declared appropriately using the new DSL style.ktor-client/ktor-client-darwin/build.gradle.kts (1)
12-20: Clear Dependency SetupThe dependency declarations under the
darwinMainanddarwinTestsource sets are streamlined and correctly reference the intended projects. The new syntax enhances readability and maintains consistency across modules.ktor-server/ktor-server-servlet/build.gradle.kts (1)
11-24: Efficient Dependency DeclarationsThe dependencies for both
jvmMainandjvmTestare organized well under the Kotlin DSL block. The use of direct dependency declaration (e.g.,apivs.compileOnly/implementation) is clear and adheres to the refactoring goals.build-logic/src/main/kotlin/ktorbuild.project.client-plugin.gradle.kts (2)
1-9: Good File Structure and Plugin ApplicationThe file demonstrates proper structure with an updated license header and correct application of the
ktorbuild.project.libraryplugin. This is consistent with the overall refactoring across the project.
31-35: JS Target Dependency DeclarationThe conditional block for JS targets properly adds the required runtime-only dependency for the client JS module. This ensures clear separation of platform-specific dependencies.
ktor-server/ktor-server-plugins/ktor-server-freemarker/build.gradle.kts (2)
1-7: License and Plugin Configuration ApprovedThe file correctly includes the updated license header and applies the
ktorbuild.project.server-plugin, which fits the conventions for server plugin modules.
9-21: Streamlined Source Set Dependency DeclarationsThe dependencies within the
kotlin { sourceSets { ... } }block are clearly and efficiently declared. The simplified structure improves readability without altering the intended functionality.ktor-client/ktor-client-mock/build.gradle.kts (1)
6-8: Streamlined Plugin Configuration.
The addition of thektorbuild.project.libraryplugin aligns with the new isolated project configuration strategy, and retaining thekotlinx-serializationplugin is appropriate.ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-json/build.gradle.kts (1)
8-10: New Plugin Integration.
The introduction of thektorbuild.project.libraryplugin is correctly applied here and supports the unified build configuration across modules.ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-protobuf/build.gradle.kts (2)
8-10: Consistent Plugin Setup.
The use of thektorbuild.project.libraryplugin alongsidekotlinx-serializationis consistent with the newer configuration strategy adopted throughout the project.
12-25: Optimized Source Set Configuration.
The updated source set syntax simplifies dependency declarations forcommonMain,jvmTest, andcommonTest, mirroring the approach in other modules and thus improving maintainability.ktor-server/ktor-server-netty/build.gradle.kts (2)
9-12: Plugin Consistency and Minimalism.
Adding thektorbuild.project.libraryplugin here streamlines the configuration and is in line with the project’s goal to achieve isolated builds. The concise plugin block contributes to a cleaner setup.
26-50: Refactored Kotlin Source Sets.
The transition to using direct dependency blocks (e.g.,jvmMain.dependencies { ... }) improves readability. The conditional logic for adding native dependencies is clear and correctly positioned within the new structure.ktor-client/ktor-client-java/build.gradle.kts (2)
6-8: Updated Plugin Declarations.
The introduction of thektorbuild.project.libraryplugin here is consistent with its use in other modules, thereby supporting a unified and isolated project build configuration approach.
15-25: Streamlined Kotlin Source Sets.
The revised source set configuration, which uses direct dependency declarations forjvmMainandjvmTest, simplifies the build script and enhances its clarity without altering dependency functionality.build-logic/src/main/kotlin/ktorbuild/internal/Train.kt (3)
56-57: Good refactoring to use Gradle's providers API!Using
providers.gradleProperty("DeployVersion").orNullinstead offindPropertyis a better approach as it leverages Gradle's lazy property evaluation. This supports the project isolation goals by enabling more efficient Configuration Cache usage.
59-63: Clean implementation with the new skipSnapshotChecks variableGood extraction of the boolean condition into a descriptively named variable that makes the code more readable and maintainable.
67-67: Consistent use of providers APIThe change to use
providers.gradleProperty("build_snapshot_train").orNull.toBoolean()brings consistency to how properties are accessed throughout the codebase and improves Configuration Cache compatibility.ktor-client/ktor-client-plugins/ktor-client-json/build.gradle.kts (4)
2-2: Updated copyright year to 2025Keeping copyright notices current is good practice.
8-8: Good addition of precompiled pluginAdding the
ktorbuild.project.client-pluginaligns with the PR goal of enhancing build infrastructure with precompiled script plugins, making the project more self-contained.
15-17: Clean dependency declarationThe simplified dependency declaration improves readability and maintainability by directly specifying project dependencies.
18-20: Consistent approach to dependency managementThis follows the same pattern as the commonTest dependencies, creating a consistent approach throughout the build files.
ktor-client/ktor-client-tests/build.gradle.kts (5)
8-8: Good addition of internal project pluginAdding the
ktorbuild.project.internalplugin supports the PR goal of enhancing build infrastructure with precompiled script plugins.
13-31: Improved source set configuration structureThe refactored Kotlin source sets use a cleaner, more direct syntax that improves readability and maintainability. This structure reduces nesting and provides a more consistent pattern across build files.
43-56: Simplified dependency declarationsMaintaining the same structure for dependency declarations across different source sets creates consistency throughout the build system.
67-69: Consistent formatting for darwinTest dependenciesThe simplified, properly indented dependency declarations for darwinTest improve readability.
71-73: Consistent formatting for windowsTest dependenciesThe simplified, properly indented dependency declaration for windowsTest follows the same pattern as other source sets.
ktor-dokka/build.gradle.kts (5)
5-5: Simplified importsUpdating to use the wildcard import for ktorbuild.* makes the code cleaner.
32-32: Updated path resolution methodUsing
resolveinstead ofdiraligns with standard path handling conventions in Gradle.
36-38: Simplified dependency declarationThe cleaner dependency declaration for dokkaHtmlPlugin improves readability and follows modern Gradle conventions.
40-44: Excellent use of project tags and lazy dependency managementGreat implementation using project tags to collect library projects and lazily adding them to the Dokka configuration. This aligns perfectly with the PR goal of using Lazy APIs for aggregating projects and leveraging the new ProjectTagService.
46-49: Improved property resolution with providers APIChanging to use
providers.gradleProperty().orNullinstead offindPropertyis consistent with changes in other files and leverages Gradle's Configuration Cache capabilities. The return type change fromDirectory?toFile?makes the function more compatible with standard Java/Kotlin file APIs.build-logic/src/main/kotlin/ktorbuild/internal/publish/ValidatePublishedArtifactsTask.kt (3)
7-8: Added Gradle provider-based utilities for better lazy evaluationThese imports introduce utilities that will help implement lazy evaluation with Gradle's Provider API, which aligns with the PR objective of improving project isolation and build infrastructure.
58-62: Improved task property configuration with Gradle providersThe code now uses
directoryProviderandregularFileProviderto configure task properties, which provides better lazy evaluation and aligns with Gradle's Provider API best practices. This refactoring supports the PR objective of implementing lazy evaluation for project settings.
134-135:✅ Verification successful
Changed return type from Provider to File
The
locateTestRepository()function now returns aFileinstead of aProvider<Directory>. This simplifies the API but changes how the function is consumed. This change appears to be part of a larger refactoring to use provider wrappers at the call site (as seen in line 59) rather than having the function itself return providers.
🏁 Script executed:
#!/bin/bash # Check for other usages of locateTestRepository() to verify they've all been updated rg "locateTestRepository\(\)" --type kotlin -A 2 -B 2Length of output: 2388
Refactoring verified: File return type is consistently applied
The change to return a
FilefromlocateTestRepository()is consistently reflected throughout the codebase. All call sites—such as in the Gradle script (usingdelete(locateTestRepository())) and withinValidatePublishedArtifactsTask.kt(wrapped indirectoryProvider { locateTestRepository() }and passed tosetUrl(...))—have been updated to accommodate the new return type. This confirms that the API simplification is correctly implemented as part of the broader refactoring.ktor-client/ktor-client-core/build.gradle.kts (3)
2-2: Updated copyright year to 2025Simple update to the copyright year.
7-9: Added ktorbuild.project.library pluginThis plugin likely encapsulates common configuration for library projects, reducing duplication across build scripts. This change aligns with the PR objective of enhancing build infrastructure and improving project isolation.
11-39: Restructured Kotlin source sets for better readabilityThe Kotlin source sets configuration has been significantly simplified, replacing nested blocks with a more direct approach where dependencies are specified directly under each source set. This change improves readability and maintainability of the build script while keeping the same functional dependencies.
The new syntax leverages the
KotlinMultiplatformSourceSetConventionsfrom Kotlin 1.9.20 as mentioned in the PR objectives.build-logic/src/main/kotlin/ktorbuild/dsl/Collections.kt (4)
1-7: New Kotlin utility file with appropriate header and suppressionThis new file includes the proper copyright header and uses
@file:Suppress("PackageDirectoryMismatch")to ensure these utility functions are available without explicit imports, which is a common pattern for DSL utility functions.
12-14: Added maybeRegister utility function for NamedDomainObjectContainerThis utility function provides conditional registration for named domain objects, allowing code to either get an existing object or create a new one if it doesn't exist. This simplifies configuration code and reduces boilerplate, supporting the PR goal of enhancing build infrastructure.
16-18: Added mapValue extension for Provider<Iterable>This extension function enhances the Provider API by allowing transformations of iterable values within providers. This utility makes it easier to work with Gradle's provider API and supports the lazy evaluation model, aligning with the PR objective of implementing Lazy APIs.
19-20: Added flatMapValue extension for Provider<Iterable>Similar to
mapValue, this extension function supports flattening transformations of iterable values within providers. This is a useful addition to the Provider API that contributes to the goal of enhancing build infrastructure with better lazy evaluation support.ktor-server/ktor-server-tests/build.gradle.kts (2)
8-8: Added ktorbuild.project.internal pluginThis plugin likely encapsulates common configuration for internal projects, which helps standardize build configuration across the codebase. This change supports the PR objective of enhancing build infrastructure and improving project isolation.
12-25: Restructured Kotlin source sets configurationSimilar to the changes in other build scripts, the Kotlin source sets configuration has been simplified to use a more direct approach where dependencies are defined directly under each source set. This improves readability and maintainability while keeping the same functional dependencies.
This consistent restructuring across build scripts ensures a standardized approach to project configuration.
ktor-java-modules-test/build.gradle.kts (6)
5-5: Updated imports to use Kotlin DSL-style importThe import has been modernized to use the Kotlin DSL-style wildcard import for ktorbuild, making it cleaner and more idiomatic.
8-11: Migrated to precompiled script plugin architectureThe build script now uses the
ktorbuild.baseplugin instead of directly applying configuration, in line with the PR objective to enhance build infrastructure with precompiled script plugins.
15-15: Improved project filtering using tag-based selectionReplacing direct filtering with the tag-based project selection mechanism improves maintainability and aligns with the PR goal of making projects more isolated.
17-19: Enhanced task input handling with Provider APIThe task now uses Gradle's Provider API through
mapValue, which ensures proper task input tracking and supports Gradle's configuration caching capabilities.
30-35: Improved file writing with correct Provider API usageThe code now correctly uses
modules.get()to retrieve values from the Provider at execution time rather than configuration time, which is important for Gradle's execution model.
55-57: Refactored dependency configuration with Lazy APIsDependencies are now added using Gradle's Lazy APIs (
addAllLater) along withmapValue, replacing manual iteration over subprojects. This improves build performance by deferring dependency resolution until necessary.ktor-server/ktor-server-plugins/ktor-server-websockets/build.gradle.kts (3)
2-2: Updated copyright yearCopyright notice has been updated to 2025.
7-9: Added server plugin configuration through precompiled script pluginAdded the
ktorbuild.project.server-pluginfor standardized server plugin configuration, eliminating the need for repetitive boilerplate across server plugin modules.
11-27: Simplified Kotlin source set configurationThe build script has been restructured to use a flatter, more concise Kotlin DSL syntax for source set and dependency declarations. This modernizes the build script and reduces nesting, making it easier to read and maintain.
build-logic/src/main/kotlin/ktorbuild/targets/KtorTargets.kt (7)
5-6: Added suppression for UnstableApiUsageAdded the
@file:Suppress("UnstableApiUsage")annotation to silence warnings about using unstable Gradle APIs, which is appropriate for build infrastructure code.
14-19: Added imports for Gradle Problem APIAdded imports for Gradle's Problem API, which is used to provide better error reporting for source set validation issues.
233-233: Added source set freezing mechanismAdded call to
freezeSourceSets()to ensure source sets are consistent after target configuration, preventing unexpected source set additions.
237-245: Added constants and problem definitions for source set validationDefined constants and problem identifiers to support the source set validation mechanism, making error reporting more structured and consistent.
246-272: Implemented source set freezing functionalityAdded the
freezeSourceSets()function which prevents unauthorized additions of source sets after initial configuration. This enforces a more structured approach to project configuration and avoids accidental source set creation, supporting the PR's goal of enhancing build infrastructure.The implementation properly handles both error and warning cases based on property configuration.
274-278: Added warning reporting for extra source setsAdded extension function to report warnings when extra source sets are detected but ignored due to the property setting.
279-308: Added comprehensive error reporting for extra source setsImplemented detailed error reporting with context information, possible causes, and suggested solutions when unauthorized source sets are detected. This significantly improves the developer experience by providing actionable guidance rather than cryptic error messages.
ktor-shared/ktor-serialization/ktor-serialization-kotlinx/ktor-serialization-kotlinx-cbor/build.gradle.kts (4)
1-3: Good addition of copyright noticeThe addition of the copyright notice is consistent with good practices for file headers.
8-8: Migration to precompiled script pluginUsing the
ktorbuild.project.libraryplugin aligns with the PR objective of implementing precompiled script plugins to make projects self-contained. This should help with configuration isolation and better build performance.
12-14: Simplified Kotlin source set configurationThe new syntax for Kotlin source sets is more concise and reduces nesting, aligning with the PR objective of utilizing the Kotlin 1.9.20's
KotlinMultiplatformSourceSetConventions. This improves readability of the build script.
18-18: Consistent source set configuration styleThis change applies the same simplified syntax to the commonTest source set, maintaining consistency throughout the file.
build-logic/src/main/kotlin/ktorbuild/dsl/KotlinSourceSets.kt (2)
1-14: Well-structured header and type aliasesGood use of file-level documentation, experimental API opt-in, and clear type aliases that improve code readability.
16-24:❓ Verification inconclusive
Good extension of Kotlin multiplatform source set conventions
The additional accessors for platform-specific source sets (posix, darwin, desktop, windows) nicely complement the built-in conventions from
KotlinMultiplatformSourceSetConventions. Using theKotlinSourceSetConventiondelegate provides a consistent and maintainable approach.It's worth verifying that these source set conventions are used consistently across the project. Consider running a simple check:
🏁 Script executed:
#!/bin/bash # Check for usage of these source set conventions across the project rg -l "\.posixMain|\.darwinMain|\.desktopMain|\.windowsMain" --type kotlinLength of output: 138
Verify consistent usage of platform-specific source sets
The extension accessors defined in
build-logic/src/main/kotlin/ktorbuild/dsl/KotlinSourceSets.ktare well implemented, and the use of theKotlinSourceSetConventiondelegate is a clean and maintainable approach. However, our repository-wide search confirms that these accessors (e.g..posixMain,.darwinMain,.desktopMain,.windowsMain) currently appear only in this declaration file. If these properties are meant to be consumed indirectly through the DSL or build configurations, then this behavior is expected. Otherwise, you might want to ensure that their usage is consistent across relevant modules.
- Action: Please verify that the DSL or build scripts correctly utilize these accessors as intended.
build-logic/src/main/kotlin/ktorbuild/ProjectTagsService.kt (5)
1-61: Well-designed ProjectTagsService implementationThe
ProjectTagsServiceis well-implemented with clear internal API for tag management. The service pattern with registration through the Gradle shared services is appropriate. Good use of MapProperty for storing project tags and proper finalization before access ingetTagged().
63-66: Clean extension function for tag additionSimple and effective extension function that makes tag assignment more concise.
68-91: Excellent documentation for projectsWithTag functionThe documentation clearly explains the function's purpose and, most importantly, highlights the distinction between eager and lazy APIs with practical examples. This helps prevent potential build performance issues.
93-104: Good use of laziness for project evaluationThe implementation properly postpones project evaluation using the provider API, which supports the PR objective of making projects isolated and efficient with configuration-on-demand.
106-113: Clever approach to ensuring project evaluationThe
ensureAllProjectsEvaluatedmethod intelligently ensures that non-meta projects are evaluated when needed, while avoiding circular evaluation dependencies between meta projects.
build-logic/src/main/kotlin/ktorbuild.project.client-plugin.gradle.kts
Outdated
Show resolved
Hide resolved
| */ | ||
|
|
||
| plugins { | ||
| id("ktorbuild.project.library") |
There was a problem hiding this comment.
It would be nice if we had some helpers in buildSrc to simplify this expression since it's everywhere. Like fun library() = plugins { id("ktorbuild.project.library") }. I'm guessing there's reasons that make this impossible or undesirable though...
There was a problem hiding this comment.
It think we could introduce accessors for plugins, like this:
plugins {
ktorbuild.project.library
}I don't want to hide plugins block behind shortcut because projects can have more than one plugin applied.
There was a problem hiding this comment.
Ah. I forgot that plugins {} block is very special. Gradle extracts it from build script and compiles separately, so it has some limitations. Extension-functions declared in build-logic aren't available in this block.
|
Can you merge main into 3.2.0-eap after this is merged? I think it'll need a bit of resolving. |
Projects without plugins won't compile as |
osipxd
force-pushed
the
osipxd/precompiled-script-plugins
branch
from
63abd23 to
8921e78
Compare
osipxd
force-pushed
the
osipxd/precompiled-script-plugins
branch
from
8921e78 to
0e02db3
Compare
Subsystem
Build Infrastructure
Motivation
KTOR-7743 Refactor Gradle configuration to use precompiled script plugins
KTOR-8336 Remove empty artifacts from publication
Solution
Removed cross-project configuration. Plugins are applied in the project build script instead, so projects are self-content. This change removes coupling between projects and allows us to use configuration on demand (now) and isolated projects (in the future).
Changed dependency declaration syntax to use
KotlinMultiplatformSourceSetConventionsintroduced in Kotlin 1.9.20.The new style is the same in terms of maximum nesting, but it has two advantages:
Refactored aggregating projects to use Lazy APIs.
We have aggregating projects - projects using outputs of all other projects. As soon as our projects became independent, we should explicitly declare that evaluation of these projects depends on evaluation of all other projects. Moreover, evaluation should be done lazily, otherwise all projects might be evaluated without need.
I've introduced
ProjectTagServiceas a point of synchronization between "aggregating projects" and ordinary projects.(Thanks to kotlin-wrappers and @adam-enko for the idea).
It's better review commit-by-commit.