[was "Re: [i18n PATCH] Adding provider qualifying"]
At 2005-05-19 16:41, you wrote:
But, to be honest, I'm a bit disappointed at how this project is being developed. I feel that i18n would benefit tremendously by reusing instead of reinventing.
Since Commons Resources and i18n seems to basically solve the same problem, my very first post to this list a month ago included the question whether i18n and Resources were going to continue to co-exist, and what was the relationship between them. After getting the impression they would continue to co-exist i18n was the natural choice because of our prerequisites.
In our project we store the language specific texts in a database. Among 60+ tables there are a few that contain several columns to provide - for example - text, abbreviated text and detailed description for a single ID + language/locale entry. So supporting multiple texts per ID is a basic requirement for us.
As was pointed out months ago, there's just too much you get for free by leveraging other components and communities.
With all do respect to those of you working on i18n, I'm not currently using this component in my own work, but I plan to in the near future. At that time I'll most likely fork the code, strip out the bottom half (dealing with message retrieval) and plug in commons-resources.
To be honest I haven't really considered building i18n *on top of* commons-resources before. But - even though I have not studied the Resources API in details - I must disapprove since I do not see an obvious/useful way to handle the above scenario using Resources.
For this to be supported by Resources in a useful manner, Resources needs to be extended. And if Resources is extended in such a way, we might just as well move what is left in i18n into the Resources component as well.
I have no interest in trying to redo my work from Commons Resources or reimplement the 3 Database-based impls of such.
And what about the hundreds of JUnit tests. One thing I've been working on lately is getting Resources to 100% test coverage. I would hate to ask someone to redo their work because I "didn't want to depend on another project".
Another idea would be to add a CommonsResourcesProvider wich you could opt to use with i18n.
FYI, I have assured i18n has 100% test coverage.
The coverage report is not currently included in the build, but if somebody would add emma.jar and emma_ant.jar to the lib dir, I could provide an updated build.xml.
/Mattias Jiderhamn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
