jdaugherty commented on code in PR #16011: URL: https://github.com/apache/grails-core/pull/16011#discussion_r3610969298
########## grails-test-examples/legacy-commands-plugin/build.gradle: ########## @@ -0,0 +1,45 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * https://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +plugins { + id 'org.apache.grails.buildsrc.properties' + id 'org.apache.grails.buildsrc.dependency-validator' + id 'org.apache.grails.buildsrc.compile' + id 'org.apache.grails.buildsrc.vulnerability-scan' + id 'org.apache.grails.gradle.grails-plugin' +} + +version = '0.0.1' +group = 'legacy.commands.plugin' + +dependencies { + implementation platform(project(':grails-bom')) + + // This fixture recompiles legacy command sources against Grails 8's grails-core-cli to + // validate discovery, adapter, registry, and runner wiring end-to-end. It does not + // re-validate a pre-compiled Grails 7 binary's Groovy-trait ABI. That relies on Groovy's + // stable trait encoding across 4->5 and could be strengthened later with a prebuilt Grails 7 + // fixture jar. + compileOnly 'org.apache.grails:grails-core-cli' Review Comment: @jamesfredley The premise that the monorepo precludes this fixture isn't right — the build already solves exactly this problem with composite builds. The root `settings.gradle` does `includeBuild('./grails-gradle')` and `includeBuild('./build-logic')`, and `grails-forge` is a fully independent build in the same repo. An included build brings its own `settings.gradle`, its own dependency/version management, and its own toolchain configuration; nothing from the root build's BOM, Groovy 5 pins, or convention plugins leaks into it. So the "Groovy 4 toolchain island" isn't something we'd have to stand up against the build architecture — it's the architecture's existing pattern: 1. a `legacy-commands-grails7` that is a Grails Plugin & **included build** pinned to the published `org.apache.grails:grails-core:7.1.1` (resolved from Maven Central, not this repo) with the Grails 7 Groovy 4 toolchain, producing a genuine trait-consumer plugin jar exactly as plugins exist in the wild; 2. the existing Grails 8 `legacy-commands` test app consuming that jar unchanged and executing its commands through the registry/runner/Gradle-task path. That's the two-app pair you've already agreed is the right test, and the composite-build boundary is what makes it *prove* the claim: the legacy half is compiled by a real Grails 7 toolchain with no possibility of accidentally resolving this repo's Groovy 5 artifacts. It also costs nothing elsewhere — `grails-test-examples` aren't part of the reproducibility/verification surface, so this adds no burden there. On scope: this PR's headline claim is that unchanged, already-published Grails 7 command plugins keep working. Merging a backwards-compatibility layer without the test that demonstrates backwards compatibility means committing to the contract on faith and discovering any trait-ABI gap later, after the layer's design is settled. You've already agreed the test must be green before release — since the mechanism to build it is the repo's existing composite-build pattern rather than a new toolchain island, I don't see what deferring buys us. It belongs in this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
