search

Unidata / geoapi-netcdf-java

netCDF-Java wrappers for the OGC GeoAPI
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

Which package name and module name? #4

Open desruisseaux opened 3 years ago

desruisseaux commented 3 years ago

What should be the package name, and what should be the module name (in anticipation for Java 9 Jigsaw)? Current proposal is edu.ucar.geoapi for both package and module name.

desruisseaux commented 3 years ago

Correction: the rest of UCAR library as seen in javadoc starts with ucar. So I will change above proposal to ucar.geoapi (for now) and update the pull request #1.

lesserwhirls commented 3 years ago

ucar.geoapi sounds good to me.

desruisseaux commented 3 years ago

Thanks. One minor question: I saw that the package names are ucar.* but Maven groupId are edu.ucar. Does Unidata have a policy for Java 9 Jigsaw module names? Is the plan to follow package names or Maven groupId names? (i.e. with or without "edu." prefix in module names?)

lesserwhirls commented 3 years ago

We don't have a plan for Jigsaw module names yet, although we're getting to that point very soon. I think going with the more unique option would be better, so I lean towards using the "edu." prefix in the module name. That makes me wonder if we should start moving towards a more unique package name as well, when we can (like when starting something new). So maybe we should put this work under edu.ucar.unidata.geoapi?

Let me bring @JohnLCaron into this conversation to get his opinion.

JohnLCaron commented 3 years ago

Would we have to change our code to edu.ucar? Or is this is just a Jigsaw module naming thing. If so, I dont have any objections to edu.ucar.

lesserwhirls commented 3 years ago

We would not have to change our existing packages to prefix with edu.ucar or edu.ucar.unidata - this would just impact the Jigsaw module naming. I also suggested that we start using the prefix edu.ucar.unidata for new work (including new work in netCDF-Java) to make things more unique.

But, since I don't know the history of our package naming conventions, I thought I'd bring you into the conversation. It's a larger topic, for sure, but I see we have package names like ucar.*, thedds.*, ucar.unidata.*, and I never quite understood how we ended up with that as opposed to something like edu.ucar.unidata.*, edu.ucar.unidata.thredds, etc., unless it's understood that Unidata has "ownership" of the ucar and thredds top level packages?

JohnLCaron commented 3 years ago

I wouldn't say there's any rhyme or reason to it.