[PROJ] Put PROJ-JNI bindings under PROJ wing?

[Howard Butler]

Martin,

I am also not enthusiastic about putting bindings inside the PROJ tree. 

* They rot without developer attention. It's not fair to burden the main project with the burden of ongoing maintenance of them. You can volunteer for now, but your attention might wane, and then the project must either jettison them (which we've done once before with Java bindings) or carry the load itself.
* They can't be forked easily and picked up by another interested developer. They're stuck interacting with the main project.
* They end up being pinned to the release cadence of the main project. PROJ's release cadence is slow. A bindings set might want to innovate and release quickly, or release at a schedule that corresponds to features of the bindings language itself, not PROJ.

Howard


> On Apr 16, 2020, at 3:07 PM, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> Martin,
>  
> at the very least, those new gen bindings should be mentionned in the documentation in https://proj.org/development/bindings.html <https://proj.org/development/bindings.html> . Please submit a PR.
>  
> My personal view, not speaking on behalf of the PSC:
>  
> Regarding putting them more formally under PROJ umbrella, I'm less convinced. We would need more than one person in the team with deep interest in them, and I'm not sure that's currently the case. Other bindings exist by themselves, with their own way of managing themselves, with very good cooperation with PROJ core when needed, and some really shine with this setup. I'm not sure why having PROJ-JNI under PROJ umbrella or not would change your interest in it.
>  
> If you're looking for some kind of official affiliation, I guess you could apply to register PROJ-JNI as a OSGeo community project. The requirements for that are pretty low (much less than a OSGeo graduated project). Regarding hosting of the git repo itself, having it under github.com/OSGeo <http://github.com/OSGeo> could have some disadvantages as we share some CI ressources like Travis-CI and AppVeyor at the organization level, and they are already quite heavily stressed by existing projects (especially for AppVeyor where we only have 1 concurrent build for the whole organization and delays of several hours can happen).
>  
> The existence of the separate PROJ-data git repo is mostly because of its large size.
>  
> Even
>  
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com <http://www.spatialys.com/>_______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org <mailto:PROJ at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/proj <https://lists.osgeo.org/mailman/listinfo/proj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200416/106a62ba/attachment.html>