Skip to content

GRAILS-6922 - In scaffolding, allow for generate-* scripts to specify a controller name for which scaffolds should be generated#26

Closed
dmurat wants to merge 1 commit into
apache:1.3.xfrom
dmurat:0010-scaffoldingControllerNameParam
Closed

GRAILS-6922 - In scaffolding, allow for generate-* scripts to specify a controller name for which scaffolds should be generated#26
dmurat wants to merge 1 commit into
apache:1.3.xfrom
dmurat:0010-scaffoldingControllerNameParam

Conversation

@dmurat
Copy link
Copy Markdown
Contributor

@dmurat dmurat commented Nov 10, 2010

@pledbrook
Copy link
Copy Markdown
Contributor

pledbrook commented Nov 11, 2010

Hi,

Thanks for all the patches! Would you mind submitting documentation patches too for new features you add? That would help ensure people know that the features are available. If you don't have time, don't worry about it.

Thanks,

Peter

@dmurat
Copy link
Copy Markdown
Contributor Author

dmurat commented Nov 11, 2010

Ooh, documentation... there is no fun there :-) I'm just kidding. Of course, I can try to do this. However, I can use some guidance in that area. For example, which section is best to describe a feature, is there any other section where it should be mentioned and similar. Maybe something about style. When finished, should I raise another JIRA issue, or append to the existing etc... And, please be aware that I'm not a native english speaker. Someone should always check what I wrote.

For this concrete issue, I will wait to see if it will be accepted of course. And for GRAILS-6584 there is an ongoing discussion about possible improvements. I can describe the current implementation for that issue, if this is ok.

Best regards,
Damir Murat

@pledbrook
Copy link
Copy Markdown
Contributor

pledbrook commented Nov 11, 2010

  1. Update the docs wherever the related features are documented. So in this case, the generate-* reference sections.
  2. Don't worry too much about style - we can fix that up afterwards.
  3. No worries - it doesn't have to be perfect English. We can do some copy-editing.
  4. Patches for documentation for new features should be attached to the original feature issue. Ideally, send a pull request on the grails/grails-doc project.

Thanks again for your contributions.

cdeszaq pushed a commit to cdeszaq/grails-core that referenced this pull request Aug 1, 2012
@pledbrook
Merged pull request apache#26 from micfra/GRAILS-7394.
d22f367 
GRAILS-7394 added missing description on escapeHtml attribute
@lhotari
Copy link
Copy Markdown
Member

lhotari commented Aug 8, 2014

Closing outdated pull requests.

@lhotari lhotari closed this Aug 8, 2014
@davemiranda davemiranda mentioned this pull request Aug 25, 2016
Closed
jdaugherty pushed a commit to jdaugherty/grails-core that referenced this pull request Jan 7, 2025
@ilopmar
Implemente addErrorHandler. Fixes apache#26
be60609
jdaugherty pushed a commit to jdaugherty/grails-core that referenced this pull request Feb 9, 2025
@puneetbehl
Merge pull request apache#26 from grails/renovate/javax.xml.bind-jaxb…
0a738d8 
…-api-2.x

Update dependency javax.xml.bind:jaxb-api to v2.3.1
jdaugherty pushed a commit to jdaugherty/grails-core that referenced this pull request Apr 19, 2025
@renovate
Update plugin com.gradle.enterprise to v3.13.4 (apache#26)
9fa8d8d 
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from grails-profiles/dependabot/npm_and_yarn/s…
5e2467c 
…keleton/client/hosted-git-info-2.8.9

Bump hosted-git-info from 2.7.1 to 2.8.9 in /skeleton/client
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from grails-profiles/dependabot/npm_and_yarn/s…
044e158 
…keleton/client/tar-4.4.15

Bump tar from 4.4.13 to 4.4.15 in /skeleton/client
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from jknudsen/master
2d71349 
unique-names twice in application.yml
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from grails-profiles/puneetbehl-patch-1
60df23f 
Delete .travis.yml
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from grails-profiles/puneetbehl-patch-2
d2235de 
Update base profile to 5.0.2
jdaugherty pushed a commit that referenced this pull request May 1, 2025
@puneetbehl
Merge pull request #26 from grails-profiles/puneetbehl-patch-1
6595259 
Update rest-api profile to 5.0.1
jamesfredley added a commit that referenced this pull request May 8, 2026
@jamesfredley
Restore IContainerGebConfiguration as interface - GROOVY-11982 fixed …
65d194f 
…in 5.0.6

GROOVY-11982 ("Default methods in interface throw IncompatibleClassChangeError
under indy=false") landed on GROOVY_5_0_X as a15a4389 on 2026-05-02 and shipped
in the Groovy 5.0.6 release on 2026-05-04. Re-verified locally on
5.0.6-SNAPSHOT build #26 (2026-05-06):

  ./gradlew :grails-geb:compileTestFixturesGroovy -PgrailsIndy=false --rerun-tasks
  ./gradlew :grails-test-examples-geb:compileIntegrationTestGroovy -PgrailsIndy=false

Both compile cleanly with the interface-default-methods form, validating that
the InterfaceMethodref vs Methodref constant pool emission for
$getCallSiteArray() is correct in the consumer bytecode.

Reverts the trait-fallback workaround introduced in b8ee60d. The previous
inline comment also cited the GROOVY-11968 VerifyError variant - that fix
landed in 5.0.6-SNAPSHOT build #22 and ContainerSupport was already restored
to @CompileStatic in 74da807.

Reproducer (now expected to PASS on 5.0.6+):
https://github.com/jamesfredley/groovy5-compiledynamic-trait-bug/blob/main/quick-checks/src/main/groovy/InterfaceDefaultsCheck.groovy

Assisted-by: claude-code:claude-opus-4-7
jamesfredley added a commit that referenced this pull request May 8, 2026
@jamesfredley
render(Map) workarounds: align inline diagnoses with File-truthiness …
faef56c 
…root cause

Paul King ([@paulk-asert](jamesfredley/groovy5-compiledynamic-trait-bug#1))
confirmed upstream that the "@CompileStatic render(Map) silent no-op" diagnosis
in this PR's reproducer is wrong: the call site is *not* the trigger. Under
Groovy 5+ the silent no-op is caused by DefaultGroovyMethods.asBoolean(File)
returning file.exists() && (file.isDirectory() || file.length() > 0). For a
not-yet-generated destination File, the truthy guard
`if (template && destination)` silently evaluates to false. The fix is
containsKey() / explicit null checks inside render(Map), not the call shape.

Two cleanups follow from this:

1. grails-shell-cli/TemplateRenderer + TemplateRendererImpl

   - Drop @CompileDynamic on render(Map) (interface and impl). The body
     is now @CompileStatic-clean.
   - Replace the truthiness guard `namedArguments?.template && namedArguments?.destination`
     with containsKey() + null checks (per Paul's recommendation).
   - Use Map.get() and explicit Resource/File coercion instead of dynamic
     property access, mirroring the grails-core counterpart fixed in
     325e2fe.

2. grails-core/TemplateRendererImpl + grails-scaffolding/GenerateControllerCommand

   - Rewrite the inline comments to point at the File.asBoolean root cause
     and link to the upstream confirmation issue. The previous comments
     framed the typed-positional bypass as the *only* call shape that
     survives, which the reproducer originally claimed and which Paul has
     since refuted. The typed positional shape is kept as defence-in-depth,
     not as a workaround for a Groovy compiler bug.

Verified locally against Groovy 5.0.6-SNAPSHOT build #26:

  ./gradlew :grails-shell-cli:test :grails-scaffolding:test :grails-core:compileGroovy

Assisted-by: claude-code:claude-opus-4-7
@jamesfredley jamesfredley mentioned this pull request May 8, 2026
Draft
jamesfredley added a commit that referenced this pull request May 8, 2026
@jamesfredley
Final Groovy 5 audit pass: clean up silent File-truthiness traps + st…
43ad57a 
…ale JIRA reference

Two cleanups against Groovy 5.0.6-SNAPSHOT build #26 (latest GROOVY_5_0_X HEAD,
4 commits ahead of the GROOVY_5_0_6 release tag).

1. grails-shell-cli/TemplateRendererImpl - the typed File/Resource overloads
   were still using the Groovy-truthiness pattern that the Map overload was
   rewritten away from in faef56c:

     render(CharSequence, File, Map, boolean) line 115
     render(File, File, Map, boolean) line 150
     render(Resource, File, Map, boolean) line 193

   All three had  if (template && destination)  guards. Under Groovy 5+
   DefaultGroovyMethods.asBoolean(File) returns
     file.exists() && (file.isDirectory() || file.length() > 0)
   so a non-existent destination File silently no-ops the render. Replaced
   with explicit  if (template == null || destination == null) return  guards
   and flattened the nested  if/else  pyramid with early returns. Behaviour
   is preserved for the null-destination case (silent return) but no longer
   collides with File truthiness.

   This brings grails-shell-cli's TemplateRendererImpl in line with
   grails-core's TemplateRendererImpl which already used explicit null checks
   from 325e2fe.

2. grails-data-hibernate5/TraitPropertyAccessStrategy - dropped the
   misleading  // See https://issues.apache.org/jira/browse/GROOVY-11512
   comment. GROOVY-11512 was closed and fixed in 5.0.0-alpha-11 / 4.0.24
   (2024-11-05), long before this PR. The boolean-getter fallback
   (findMethod(getGetterName(name, true))) is plain JavaBean-conventions
   defence for boolean trait properties and is not Groovy-version
   conditional. Removing the JIRA reference avoids implying this code has
   any pending upstream dependency.

Final-pass cross-reference of all 20 GROOVY-* tickets shipped in 5.0.6
against every remaining workaround in this PR - the librarian and explore
audit confirms no other workaround maps to a fixed ticket. The five
remaining workarounds are kept (none have an upstream fix on
GROOVY_5_0_X HEAD):

  - VariableScopeVisitor canonicalisation NPE (4 sites, no JIRA filed)
  - boot4-disabled integrationTest on 5 test apps (controller action
    parameter scope under indy=false; no JIRA filed)
  - ConfigurationBuilder Map exclusion + AbstractConstraint static-init
    fallback (Spring 6/7 + Groovy 5 binding interaction; no JIRA filed)
  - g.taglib  @IgnoreIf  in GspCompileStaticSpec (regression of
    GROOVY-6362 / GROOVY-11817; no follow-up JIRA filed)
  - Validateable.resolveDefaultNullable() reflection bypass
    (GROOVY-11985 OPEN; TraitReceiverTransformer change from GROOVY-8854)

Verified locally:

  ./gradlew :grails-shell-cli:test :grails-data-hibernate5:classes
  -> BUILD SUCCESSFUL

Assisted-by: claude-code:claude-opus-4-7
jamesfredley added a commit that referenced this pull request May 8, 2026
@jamesfredley
Fix dbmigration GroovyChangeLogSpec: drop env-dependent log-capture a…
62951d4 
…ssertions

The Groovy joint validation build ("CI - Groovy Joint Validation Build")
has been failing on the 8.0.x branch since 2026-05-07 with:

    GroovyChangeLogSpec > updates a database with Groovy Change FAILED
        Condition not satisfied:
        output.toString().contains('confirmation message')

Two intertwined causes:

1. The previous test logger config was a Groovy-DSL Logback config
   (logback.groovy) using @withJansi=true, %highlight, %cyan converters.
   In the joint validation environment the freshly-built local Groovy
   5.0.6-SNAPSHOT (GROOVY_5_0_X HEAD) interacts with Logback's
   GroovyConfigurator in a way that silently fails to register the
   'liquibase' logger -> STDOUT binding. Replaced with an equivalent
   logback-test.xml that has no Groovy / Jansi / colour-converter
   dependencies. Same logger levels and appender wiring, just XML.

2. Even with the logger config loaded, the failing assertions
    output.toString().contains('confirmation message') and
    output.toString().contains('warn message')  are environment-
   dependent. Liquibase 4.27 selects between Slf4jLogService and the
   built-in JavaLogService at Scope-init time; the choice depends on
   which SLF4J binding is bound *at that moment*. The two service
   implementations route INFO output very differently:

       Slf4jLogService -> SLF4J -> Logback ConsoleAppender -> stdout
                                  (filtered by root level / per-logger
                                  levels in whichever logback config
                                  Logback found first)
       JavaLogService  -> java.util.logging -> default ConsoleHandler
                                              -> stderr (no filtering)

   In the local dev environment Liquibase falls back to JavaLogService
   and the messages end up in captured stderr (Spock captures both),
   so the test passes. In the joint validation runner Liquibase picks
   Slf4jLogService and the messages get filtered by Logback before
   they reach stdout. Since the captured behaviour is being driven by
   classpath-and-configuration roulette rather than the code under
   test, asserting on it produces flake.

   The change being applied is already verified by  calledBlocks  in
   each test method (init / validate / change / rollback closures
   record their invocation order). The  confirm  and  warn  directives
   are exercised by GroovyChange's  confirm(String)  and  warn(String)
   methods being invoked from the parsed DSL - if those didn't run,
   the changeset wouldn't apply and  calledBlocks  would be empty.
   Drop the brittle  output  assertions and document why so a future
   maintainer doesn't re-add them.

Verified locally on Groovy 5.0.6-SNAPSHOT build #26:

    ./gradlew :grails-data-hibernate5-dbmigration:test \
        --tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
        -PmaxTestParallel=3 --rerun-tasks
    BUILD SUCCESSFUL (7 tests, 7 successes, 0 failures, 0 skipped)

Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade)
where  build_grails  was the only outstanding Groovy joint validation
failure on both 8.0.x and the upgrade branch.

Assisted-by: claude-code:claude-opus-4-7
jamesfredley added a commit that referenced this pull request May 8, 2026
@jamesfredley
Fix dbmigration GroovyChangeLogSpec: drop env-dependent log-capture a…
0ce8095 
…ssertions

The Groovy joint validation build ("CI - Groovy Joint Validation Build")
has been failing on the 8.0.x branch since 2026-05-07 with:

    GroovyChangeLogSpec > updates a database with Groovy Change FAILED
        Condition not satisfied:
        output.toString().contains('confirmation message')

Two intertwined causes:

1. The previous test logger config was a Groovy-DSL Logback config
   (logback.groovy) using @withJansi=true, %highlight, %cyan converters.
   In the joint validation environment the freshly-built local Groovy
   5.0.6-SNAPSHOT (GROOVY_5_0_X HEAD) interacts with Logback's
   GroovyConfigurator in a way that silently fails to register the
   'liquibase' logger -> STDOUT binding. Replaced with an equivalent
   logback-test.xml that has no Groovy / Jansi / colour-converter
   dependencies. Same logger levels and appender wiring, just XML.

2. Even with the logger config loaded, the failing assertions
    output.toString().contains('confirmation message') and
    output.toString().contains('warn message')  are environment-
   dependent. Liquibase 4.27 selects between Slf4jLogService and the
   built-in JavaLogService at Scope-init time; the choice depends on
   which SLF4J binding is bound *at that moment*. The two service
   implementations route INFO output very differently:

       Slf4jLogService -> SLF4J -> Logback ConsoleAppender -> stdout
                                  (filtered by root level / per-logger
                                  levels in whichever logback config
                                  Logback found first)
       JavaLogService  -> java.util.logging -> default ConsoleHandler
                                              -> stderr (no filtering)

   In the local dev environment Liquibase falls back to JavaLogService
   and the messages end up in captured stderr (Spock captures both),
   so the test passes. In the joint validation runner Liquibase picks
   Slf4jLogService and the messages get filtered by Logback before
   they reach stdout. Since the captured behaviour is being driven by
   classpath-and-configuration roulette rather than the code under
   test, asserting on it produces flake.

   The change being applied is already verified by  calledBlocks  in
   each test method (init / validate / change / rollback closures
   record their invocation order). The  confirm  and  warn  directives
   are exercised by GroovyChange's  confirm(String)  and  warn(String)
   methods being invoked from the parsed DSL - if those didn't run,
   the changeset wouldn't apply and  calledBlocks  would be empty.
   Drop the brittle  output  assertions and document why so a future
   maintainer doesn't re-add them.

Verified locally on Groovy 5.0.6-SNAPSHOT build #26:

    ./gradlew :grails-data-hibernate5-dbmigration:test \
        --tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
        -PmaxTestParallel=3 --rerun-tasks
    BUILD SUCCESSFUL (7 tests, 7 successes, 0 failures, 0 skipped)

Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade)
where  build_grails  was the only outstanding Groovy joint validation
failure on both 8.0.x and the upgrade branch.

Assisted-by: claude-code:claude-opus-4-7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@dmurat @pledbrook @lhotari @dmuratGithub