I would be interested in hearing about concrete cases where one jar adds .properties files for a class declared in a completely different jar - I haven't seen that done in the wild before, it sounds like a bit of a stretch to me. It might also be something that we could formally discourage in the "new and improved i18n tool" docs. Alternatively, I've heard of cases where the upstream jar doesn't run the processor, but just defines the sources and lets the downstream jar run it when it provides the rest of the impl details.
At the risk of sounding like I'm speaking for the team that built the original i18n module, I see it as trying to replicate PropertyResourceBundle behavior in the JVM, without the need to have runtime access to the classpath. I could be mistaken, but using PropertyResourceBundle in the way you describe (loading .properties files from a different jar) may no longer work correctly in Java 9 anyway, at least without custom module permissions for access (somewhat akin to running or re-running the processor on the downstream project)? Might be wrong on that. Reusing that .properties format for localized files and BundleName_locale.properties file name format seems like an express design goal to me, no matter what other changes happen along the way. On Friday, January 5, 2018 at 11:33:48 AM UTC-6, Ahmad Bawaneh wrote: > > Dears > I am working on porting the *i18n* module, so far all i did is extract > the module and the tests into and external repository and make the tests > pass, not real change to the code have been yet. but the *i18n* module is > an important module and is being used by so many gwt application so porting > this one should be taken with care, this why i am opining this discussion > so that i can hear and share idea's. > > i would like to start this discussion by sharing some of my thoughts, > which are limited to my knowledge of the gwt *i18n*, and i would love to > get corrections and feedback to what ever wrong or good thinking i have. > > so first in a gwt 2.x application using *i18n* with generators assumes > that the set of locales available is known during the code generation, for > example if you an application that has a module lets call it module *A* > that define a messages interface (*MessagesA*) and defines the locales to > be `*en*`, `*fr*` for example, then once the application is compiled, the > generator should produce *MessagesA* class for each locale and we end up > with *MessagesA_en* and *MessagesA_fr* having that we provide properties > files for both. > > now assume we add a new module to our application module *B* and B > defines another messages interface *MessagesB* and extends the locale > property to add a third locale `*it*` and provide properties files for > *MessagesB > en,fr and it* and also provide a properties file for* MessagesA it*, then > when we compile we will end up with *MessagesA_en*, *MessagesA_fr*, and > *MessagesA_it*, *MessagesB_en*, *MessagesB_fr*, and *MessagesB_it*. > > with this i could extends the application messages by adding a new module > thanks to the Property oracle that provide information about all defined > and extended locales. > > now in the APT world with multi modules things are different, the > processors does not rum for all modules as one unit instead the processor > will run for a single module and will have knowledge limited to that > module, so module *A* processor wont know about locales defined in > module *B*, and module *B* processor wont know about locale values > provided by module *A*, so and expected result that i will end up with > *MessagesA_en*, *MessagesA_fr* for module *A* and *MessagesB_it* for > module *B*. > > what do you think? > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e40829d8-fbda-47b9-9516-27ea7995cc81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
