Allow other tools to utilize the CLDR API in ICU
Currently only the cldr-to-icu tools use the new CLDR API, but this should be extended to permit other tools to be refactored to use it. In particular, the LocaleDistanceBuilder can be easily converted to utilise the CLDR API and reduce code complexity.
To achieve this, the CLDR JAR file which implements the API should be moved to a more "shared" location (e.g. outside the cldr-to-icu sub-project). Once there, it can be used easily by new Maven projects in the java/tools/ directory.
My idea would be to go from:
And create a small "pom.xml" file in the lib/ directory to encapsulate the local Maven repository hack that's needed.
I'd also move the installation scripts and update the README docs (obviously).
Once the CLDR_DIR property is not needed by the library, more can be done, but that should be another ticket.
According to your last comment, I can’t see related issues anymore, so I believe it’s OK.
Thanks for the support.
Apart from the need for the CLDR_DIR system property to be set (which can only be fixed with work on the CLDR side) the rest of this is now done. The Ant scripts no longer see a clash of directories between the CLDR project and the staging data, and the library is in a more common location (which if used via Ant can leverage the same trick to avoid CLDR_DIR issues).
Do you think there’s anything else left to do here (and if so, what) ?
The new Ant scripts fork the process and set the “shadowed” CLDR_DIR variable, so there’s no longer any issue during normal running of the tools. However any additional tools using the CLDR JAR still need to set CLDR_DIR. So this isn’t strictly done, but until CLDR stops needing the CDLR_DIR variable, this is about as good is it will get.
It occurs to me that if we can fork the process we can adjust the environment variable locally in there.
Since Hugo is does things in this area now I’ve wait until he’s finishing before looking though.