Manually install netcdfAll dependency into maven repository

[srstsavage]

Hi all,

I notice that managing the netcdfAll.jar dependency is causing quite a bit of trouble now that Unidata has stopped publishing it.

Has manual installation of the jar into the developer's local maven repository been explored? After manually downloading the jar from https://artifacts.unidata.ucar.edu/#browse/browse:downloads-netcdf-java, you can use the following command to install the jar into your local maven repo:

mvn install:install-file -Dfile="/path/to/netcdfAll.jar" -DgroupId=edu.ucar -DartifactId=netcdfAll -Dversion=5.5.3 -Dpackaging=jar

Once installed, maven will be able to find the jar and the user/platform specific <systemPath> and <scope> elements on the netcdfAll dependency can be removed, making the build more portable and less brittle.

[BobSimons]

"quite a bit of trouble". You got that right!
I'm not great with maven. I've really struggled (and failed) to deal properly with this change in Maven. I have a kludge in place right now.
I hope your suggestion works, but I'll leave it to Chris John to try it.
Thanks for the suggestion.

[ChrisPJohn]

Thanks for the suggestion. I did update the path to be relative to the project (so no longer user specific) in my recent change to the dependencies, but this sounds like an even better approach. I'll take a look at using it.

[clifford-harms]

Would there be any interest in transitioning fully to a conventional maven build? By 'conventional maven build' I mean:

• fully defined dependencies in pom.xml, including the version controlled local repository for problem child dependencies as mentioned by @srstsavage
• build artifacts written to non-version controlled ./target directory
• non-java resources moved to src/main/resources/
• separate src/test directory for unit tests. I realize the existing testing architecture could not make use of this, but future easy-to-execute unit tests could

These kinds of changes would make the pom.xml much less complicated and would allow erddap to be built in a manner that most java developers nowadays are used to, which reduces barriers to contribution. A powershell and bash script can be included to build without maven as well, if necessary. I have already done all of these changes on a local fork of ERDDAP (v2.18), so barring any Java 17 complications it is definitely possible, and I would be happy to contribute.

[ChrisJohnNOAA]

If you make a pull request, I'll take a look at it. My concern with changing the directory structure is that the code has dependencies on the current directory structure, so I'll want to look more closely at those changes.