The rincl-resourcebundle artifact currently comes with a concern provider, meaning that simply including the dependency will cause the resource bundle implementation to be registered as the default resource i18n concern. This causes complications for implementations that may want to fall back to the resource bundle implementation.
Separate the actual provider into a separate dependency, e.g. rincl-resourcebundle-provider, so that rincl-resourcebundle may be included for those libraries and applications which want access to the implementation but not have a concern automatically installed.
Now the io.rincl:rincle-resourcebundle dependency will not automatically register the resource bundle implementation as a provider. Including io.rincl:rincle-resourcebundle-provider will transitively include io.rincl:rincle-resourcebundle and register the resource bundle implementation with Csar, so that everything will work automatically with resource bundles as happened in earlier versions using io.rincl:rincle-resourcebundle.
Providing a separate POM the same repository for the provider seemed like a quick-and-easy approach, but it's causing some problems. As found out in CLOGR-3, it's not as straightforward as just including or not including some provider text file. Sometimes there are tests associated with the provider. Sometimes tests rely on the provider. Plus the provider class itself has no business being in the non-provider build.
So although it seems like extra clutter, it's probably best to split out the provider and its text file into a separate rincl-resourcebundle-provider, and so on for all the other implementations such as rincl-wicket-provider. See https://globalmentor.atlassian.net/browse/CLOGR-3?focusedCommentId=13900&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13900