You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@grails.apache.org by "Taack (via GitHub)" <gi...@apache.org> on 2025/10/10 00:02:30 UTC

[I] Cannot get i18n on multi-project build when attempting bootRun with hotreload enabled [grails-core]

Taack opened a new issue, #15129:
URL: https://github.com/apache/grails-core/issues/15129

   ### Expected Behavior
   
   Translations should work as for a regular `bootRun`
   
   ### Actual Behaviour
   
   Either launching `bootRun -Dgrails.run.active=true` or using:
   
   ```groovy
   bootRun {
       doFirst {
           classpath = classpath.filter { file ->
               boolean r = true
               gradle.ext.taackPlugins.each { p ->
                   r = r && !file.path.contains(p + '-' + version + '.jar')  // Exclude the JAR to avoid duplicates
               }
               r
           }
           gradle.ext.taackPlugins.each { p ->
               classpath = classpath + project(':' + p).sourceSets.main.output  // Add classes and resources output
           }
       }
   // [. . .]
   ```
   
   Seems to results in `message.property` files not being included.
   
   
   ### Steps To Reproduce
   
   First we import the infra into local maven:
   
   1. clone the infra repo: `git clone git@github.com:Taack/infra.git`
   2. into this repo, `./gradlew publishMavenPublicationToMavenLocal`
   
   Then
   1. clone the intranet repo: `git clone git@github.com:Taack/intranet.git`
   2. swith to branch [g7s2](https://github.com/Taack/intranet/tree/g7s2): `git switch g7s2`
   3. Launch with `bootRun  -Dgrails.run.active=true` (i18n NOK, hotreload OK),  `bootRun` (i18n OK, hotreload NOK)...
   
   ### Environment Information
   
   - Linux cachyos-x8664 6.17.1-2-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 06 Oct 2025 15:17:14 +0000 x86_64 GNU/Linux
   - java full version "24.0.2+11-jvmci-b01"
   
   
   
   ### Example Application
   
   _No response_
   
   ### Version
   
   Grails 7.0.0-RC2


-- 
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: notifications-unsubscribe@grails.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Cannot get i18n on multi-project build when attempting bootRun with hotreload enabled [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3388382453

   After trying in a clean env, I cannot reproduce using `./gradlew server:bootRun  -Dgrails.run.active=true`, hotrestart is not working. So I pushed the version with the closure in bootRun (see `server/guild.gradle`), here i18n is broken but hot reload is working.
   
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487308672

   @jdaugherty hope you can find the best solution. 
   
   The issue is like:
   
   ```groovy
           String pathAbsolute = new File('grails-app').absoluteFile.path
           Resource urlResource = new UrlResource('file', pathAbsolute)
           println urlResource
           Resource relative =  urlResource.createRelative('')
           println relative
   ```
   
   Outputs:
   ```bash
   URL [file:/home/auo/Téléchargements/test-i18n-multiproject-buildSrc/server/grails-app]
   URL [file:/home/auo/Téléchargements/test-i18n-multiproject-buildSrc/server/]
   ```
   
   I choose to not call `createRelative` in case the classpath is a file, may be it is better to fix  `createRelative` but it is located outside the grails-core sourcetree ...


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487670669

   Just some more background here, it looks like when I fixed ear exploded in Grails 7 (I did have to adjust your example), the actual source files are now being passed instead of the jar file.  This is great news except when it's processing the resource directory, it's stripping the 'main' directory due to the aforementioned createRelative behavior.  
   
   Using your example application: when processing this URL [file:/myProjectPath/app/test/build/resources/main], the createRelative method is stripping the 'main' directory.  From what I can tell, the exploded behavior in Grails 6 does not correctly pass the source files.  Instead, it refers to the jar file which goes through a different path.  This is why I can't reproduce this in Grails 6.
   
   I looked at the implementation of UrlResource#createRelative, and noticed that originally it had this implementation: 
   
   	@Override
   	public Resource createRelative(String relativePath) throws MalformedURLException {
   		if (relativePath.startsWith("/")) {
   			relativePath = relativePath.substring(1);
   		}
   		return new UrlResource(new URL(this.url, relativePath));
   	}
   
   Specifically, this code:
   
          new URL(this.url, relativePath)
   
   Executing this code with the input above (relativePath is an empty string in this case), it returns a url with the same value.  https://github.com/spring-projects/spring-framework/issues/23532 was the ticket that changed this behavior in Spring.  My guess is Grails was using this in a different way?  I'm some what surprised this hasn't been reported to Spring upstream. 
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Cannot get i18n on multi-project build when attempting bootRun with hotreload enabled [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3388336893

   Just fixed the test case build (using Grails 7.0.0-RC2) and also put the propoer `bootRun` commands in the previous message...
   
   The login / password is admin / ChangeIt (see in `server/grails-app/conf/application.yml`)
   
   Thanks for your support
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: resources are not reloading or being found in exploded mode [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3488396957

   Actually, it was only required in 6.x it seems.  For some reason I thought the property was still required.


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487712381

   So the more I've thought about this, I think it's because Spring is assuming createRelative() will always be used with a file reference, so the file will be stripped.  Grails is calling it with just a folder though. It doesn't look like that was historically true, but it is now.  I'm not sure what to do in this case.  This requires further thought.


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: resources are not reloading or being found in exploded mode [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty closed issue #15129: hotreload & multi-project: resources are not reloading or being found in exploded mode
URL: https://github.com/apache/grails-core/issues/15129


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3486870640

   I've taken your test project and created a Grails 6 version with both the exploded & jar configurations in separate branches.  It's located here: https://github.com/jdaugherty/grails-issue-15129
   
   Starting to research this issue more now.


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487785705

   @Taack  Be sure to take a look at https://github.com/jdaugherty/grails-issue-15129/tree/grails7exploded - it's correctly using file paths now like Graeme's ear exploded implementation originally did.  You were missing the exploded=true property specifically.
   
   PR https://github.com/apache/grails-core/pull/15208 fixes this


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3425661454

   I just updated the test-case for Grails **7**, modifications include:
    
   * cleaned up buildSrc;
   * use for loops instead of each with closure;
   * Use Grails 7.0.0 instead of Grails 7.0.0 RC2.
   
   If you modify `app/crew/grails-app/controllers/CrewController`, the app is Hot-restarted, but **i18n** is broken.
   
   If you apply the patch provided by the pull request, **i18n** is OK.
   
   Regards
   
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3422506560

   FYI, `Resource resource = baseResource.createRelative(location);` in `org.grails.core.io.StaticResourceLoader:51` seems to shrink the resource path. I prefer to not modify anything here.
   
   Regards
   
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: resources are not reloading or being found in exploded mode [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487935973

   @jdaugherty , great, I will test tomorrow. Reading [12.21 exploded is supported again to enable multi-project reloading](https://grails.apache.org/docs/latest/guide/single.html#_12_21_exploded_is_supported_again_to_enable_multi_project_reloading), it is not clear to me if `exploded` was mandatory for Grails 7 or not... 


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3441470354

   Here is the **buildSrc** version using exploded plugin. Logging is working correctly after a hot restart. This test-case is much cleaner than previous ones.
   
   [test-i18n-multiproject-buildSrc.tar.gz](https://github.com/user-attachments/files/23114491/test-i18n-multiproject-buildSrc.tar.gz)
   
   To summarize: 
   
   - the `app` folder holds grails plugins, here, only `test` plugin is added;
   - the `server` folder is the main app;
   - we use `buildSrc` semantic to simplify all `build.gradle` into plugins and main app;
   - **i18n** is defined into **plugins**;
   - we have to launch `bootRun` task from server directory.
   
   In our use-cases, `bootRun` completely breaks the UI, because we try to find the right translation automatically iterating over many keys (from more specific to generalized ones, like `offer.salesman.usernaname.label`, then `salesman.usernaname.label`, then `user.usernaname.label`, then  `default.usernaname.label`). 


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3434072961

   Following today meeting, I could reproduce the issue with a simple test-case. The gradle files are based the ones generated by Grails forge.
   
   [test-i18n-multiproject2.tar.gz](https://github.com/user-attachments/files/23061610/test-i18n-multiproject2.tar.gz)
   
   Steps:
   ```bash
   > cd test-i18n-multiproject2/server
   > ../gradlew bootRun
   ```
   In another terminal
   ```bash
   > curl http://localhost:8080/test
   test.label
   > curl http://localhost:8080/test?lang=fr
   test.label
   ```
   `test.label` is a key, not the translation.
   
   Hot restart is working properly, but i18n is broken. The patch provided by the PR fix i18n.
   
   `test.label` is translated in the `app/test` plugin.
   
   Note: it does not work when using `./gradlew server:bootRun`, you **have to** execute gradle from the server directory.
   
   
   Hope this helps !! 


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources looks after resources into the wrong path [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3487763505

   So this issue is caused by the directory not having a trailing slash.  I don't think the right solution is to change our calls to the spring framework.  Rather, I think it's best we just fix this case and fix any more as they come up.  I'll be submitting a PR that's specific to the resource directory lookup here shortly and it should fix this ticket as a result.


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: resources are not reloading or being found in exploded mode [grails-core]

Posted by "jdaugherty (via GitHub)" <gi...@apache.org>.
jdaugherty commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3488391479

   @Taack exploded is only required for multiproject builds that need to support reloading.  The property + plugin have to exist.  See https://grails.apache.org/docs/latest/guide/plugins.html#creatingAndInstallingPlugins for more details 


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] hotreload & multi-project: doFindPathMatchingFileResources do not return resources if classpath is a non-jar path [grails-core]

Posted by "Taack (via GitHub)" <gi...@apache.org>.
Taack commented on issue #15129:
URL: https://github.com/apache/grails-core/issues/15129#issuecomment-3422164849

   After digging a little,  it turns out that `org.grails.plugins.BinaryGrailsPlugin#getProperties` does not list resources if `baseResourcesResource` (the classpath entry) point to a non-jar directory.
   
   ```groovy
               try {
                   // first load all properties
                   Resource[] resources = resolver.getResources('*' + PROPERTIES_EXTENSION);
                   resources = resources.length > 0 ? filterResources(resources, locale) : resources;
                   if (resources.length > 0) {
   ```
   `resources.length` is zero because `resolver.getResources` return an empty array.
   
   It seems `doFindPathMatchingFileResources` look after the wrong path: `.../build/resources` instead of `.../build/resources/main` where the properties are stored.
   
   
   
   
   
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org