Move over to forked nv-i18n with modern changes - #467

Thanks for flagging this, and sorry for the silent close.

You were right about the underlying problem: com.neovisionaries:nv-i18n last shipped in 2021 and is not coming back. We went a different way in 10.0.0-RC7 and dropped the dependency entirely rather than moving to the fork, so I want to explain why, because it was not a judgement on the fork itself.

10.0.0-RC7 makes the jar an explicit JPMS module. A module can only requires another module by name, and CountryCode appears in this library's public API, so the requirement would have to be requires transitive. Neither the original nor uk.co.foundationsedge:nv-i18n:1.34.1 carries a module-info or an Automatic-Module-Name, so the name in both cases is derived from the file name, nv.i18n. Baking a derived name into a published module descriptor breaks every consumer if the artifact is ever renamed or later gains a real module name, and it also stops consumers from producing a clean jlink image.

So the fork would not have unblocked what we needed here. What the library actually used was small: 35 market(CountryCode) parameters, two country parameters, one CountryCode[] field, and one LanguageCode lookup inside an assert. All of it only ever needed the alpha-2 string. It is now a vendored se.michaelthelin.spotify.enums.CountryCode generated from Locale.getISOCountries(), which keeps the constant names identical, so users migrate by changing one import.

One thing your fork was useful for regardless: I diffed its 303 constants against the generated 250 to check what was being given up. The extras are withdrawn codes, exceptionally reserved ones and non-ISO internet codes. Checked against Spotify's own market list and every available_markets array in our fixtures, XK was the only code Spotify actually uses that the JDK omits, so it is carried explicitly. Without that comparison I would probably have missed it.

Hi, that makes total sense and is understandable. @jonathan-strange and I have been working on the fork as our internal project relied on the library. We had considered just copying internally the 4 classes we used, but knew we could learn a lot by working on an open source library that would let us know the work involved in making any future greenfield ones too.

Some of the dependents of the original repo have also taken the classes into their project, or replaced them. Many had also missed how old the last update to it was. There was i.e. an update to iso country codes last week too so if you want notified of these, or the other standards, you can sign up for notifications from ISO by email here https://www.iso.org/obp/ui

Before we forked, we had chatted too about the credibility of open source projects, how you tell if one is good, and also potential supply chain issues which are more well-known in npm etc so having a prominent library point out these risks accelerated our investigations into the topic.

Two of the things we spotted were related to recognition from the OpenSSF and we've been working down a lot of their recommendations, hardening builds and configuration and similar. Having forked the library we have not only 5 years of standards to update but also some technical debt to document and fix. So hopefully we can get it to a more stable place for others in the future too.

@jonathan-strange was looking into documentation and making a sample project and then the code in another module which may cover some of the module-info gaps you mentioned, but if not I'll also add it to our todo list so we can investigate those too.

So just to say thanks - you've helped in a bunch of ways by pointing us to the kind of things we need to investigate :).