borinquenkid commented on PR #15805: URL: https://github.com/apache/grails-core/pull/15805#issuecomment-5208443722
Following up on the ASF publishing concern — I think there's a compromise that sidesteps it entirely rather than trying to find an ASF-compliant way to *route through* SkillsJars. **The governance problem is coupled to SkillsJars specifically, not to distributing skills at all.** Per @jdaugherty's finding on the rework branch, SkillsJars' own discovery/registry only indexes artifacts published through *their* scan-and-publish pipeline under `com.skillsjars:*` coordinates — publishing a jar ourselves under `org.apache.grails:*` through the normal ASF release train doesn't make it show up there. So there's no version of "publish through SkillsJars" that avoids the voting-rules conflict; the third-party publish step *is* the product. **Proposal: for `grails-developer`, stop trying to publish it at all — embed it directly into every app `grails-forge` (and/or the legacy `create-app` profiles) generates.** This repo already has the exact mechanism for this, and it ships zero new files through any third-party service: - `grails-forge` builds every generated file via `Feature.apply(GeneratorContext)` → `generatorContext.addTemplate(...)` (`DefaultProjectGenerator.java`, `Feature.java`). Static verbatim files (gradle wrapper, GSP layouts, i18n props) are already added this way as classpath resources under `grails-forge-core/src/main/resources/`. A `SKILL.md` would work identically — no new distribution channel, no new build task, no RAT carve-out, nothing outside grails-core's own already-ASF-compliant release pipeline. - The legacy `grails create-app` path (`grails-shell-cli` + `grails-profiles/*/skeleton`) could get the same file for parity, since those skeletons are just static content copied into generated apps. **Why this is actually a better fit for `grails-developer` specifically:** its whole purpose is guiding ongoing development of a Grails app — the exact moment `create-app` runs. Shipping it in the generated project puts it in front of 100% of new Grails developers automatically, with no dependency, no Maven coordinate, no separate install step. **Where this doesn't help — and I don't think we should pretend it does:** `grails-8-upgrade` targets people upgrading an *existing* pre-8 app. A freshly generated app is already on 8, so embedding it at generation time doesn't reach that audience at all. I'd suggest we don't block on solving that one here — either leave it as source docs under `.agents/skills` (discoverable via the README this PR already added) until we have a real answer, or treat it as a separate follow-up once we know what channel we actually want for "skill for an existing project" distribution (which is the same question a compliant SkillsJars-alternative would have to answer anyway). **Concretely, I'd propose:** 1. Close/pause this PR as-is (per @jamesfredley's earlier comment) rather than continue reworking the SkillsJars integration. 2. Open a new, small PR that adds a `grails-developer` feature/template to `grails-forge` (and optionally the legacy profiles) so it's seeded into every generated app. 3. Leave `grails-8-upgrade` distribution as an open question, not a blocker on #15454 — it was already satisfied by the source doc landing in #15798. Happy to put together the `grails-forge` PR if folks are on board with this direction. -- 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]
