Update documentation and modularize the Java bindings #969
Conversation
…tion update or formatting. There is no code change in this commit, except the addition of @Native annotation on a constant.
…an still be used standalone).
…aintained manually.
|
Looks good to me. Since you are now touching the documentation it would be good if you could use the correct spelling of the library: PROJ (and not Proj). I am trying to keep it consistent in all of the documentation. Am I correct in saying there is no breaking changes for users with this PR? |
|
No problem (I didn't noticed that the PROJ was all upper-case). Do I update this merge request or do we wait for the next round? There is no breaking change for users with this pull request, except that it requires Java 9 (current Java release is 10). If support for older Java versions is required, it would be possible at the cost of a more complex |
Just change it now
I think we're good as it is now then. I was mainly asking since we should not make breaking changes in minor version releases. PROJ 6 is scheduled for release early next year so that is a good opportunity to introduce breaking changes. |
- Move the jniwrap/org/ directory into the jniwrap/org.osgeo.proj/ sub-directory ("org.osgeo.proj" is the module).
- Add a module-info.java description.
- Update the Makefile.am files for referencing the files in their new location.
There is no API change at this stage; all moved classes are still the same that previous version.
|
Done. Travis build passed, waiting for AppVeyor. |
The 3 first commits are changes in the documentation only or in the use of a
#defineinstruction without any API or functional change. The last commit moves all Java classes in anorg.osgeo.projsub-directory with no change in the content of those files. This move is for leveraging a new Java feature, which supports modularization since Java 9. By moving the classes in anorg.osgeo.projdirectory, we are creating a new Java module named "org.osgeo.proj". This module name is consistent with the package name proposed in #903 (module name and package name are two different things, but for a small project like those JNI wrappers they should be the same).This merge request does not yet apply any API change. In particular the package name still have its old name (
org.proj4). Package names will be addressed later.