The orekit-data archive provided as a git repository that can be cloned or downloaded is considered to be a convenience only and people should NOT rely on it to remain available or be updated. It is often used as an initial setup for quick installation, but people MUST manage the data themselves and update them using the data sources the prefer, with a process that is suitable for their use. Some people may want different JPL or IMCCE ephemerides, some people may want to use Bulletin-B or Bulletin-A for EOP data, some people may want a different Earth gravity field or even gravity fields for other planets…
Anyway, despite of this intended use, here are my thoughts about the other points of your post.
Someone with write access just run the script in his workspace and then push the updated files (or new files) to the repository.
Note however that the script currently fails for the
tai-utc.dat file because the USNO servers are down and will remain down for several months (see IERS message 384). This is not a problem yet as we know the next leap second cannot happen before December 2020 (a bulletin D was issued recently to assert no leap second will occur in June 2020).
I like this.
This solution has a major drawbacks: it would induce dramatic performance issues. Jar format is the same as zip format, and this is not recommended for holding data, despite Orekit does support it. The reason for that is because zip/jar puts a central directory at the end of the archive and if you want to read a small file (say
tai-utc.dat), you have to read the full archive which can be huge due to JPL ephemerides, EOP data and gravity fields. This is explained in the documentation of the data-context branch (not merged yet into develop), see for example https://gitlab.orekit.org/orekit/orekit/blob/data-context/src/site/markdown/data/default-configuration.md, in the default setup section.